A KASAN enabled kernel will log something like below (decoded and stripped):

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "perf-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-72.0.0.64.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-72.0.0.64.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-72.0.0.64.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "perf-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-72.0.0.64.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-72.0.0.64.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-72.0.0.64.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naf_unix: Update unix_sk(sk)-\u0026gt;oob_skb under sk_receive_queue lock.\r\n\r\nBilly Jheng Bing-Jhong reported a race between __unix_gc() and\nqueue_oob().\r\n\r\n__unix_gc() tries to garbage-collect close()d inflight sockets,\nand then if the socket has MSG_OOB in unix_sk(sk)-\u0026gt;oob_skb, GC\nwill drop the reference and set NULL to it locklessly.\r\n\r\nHowever, the peer socket still can send MSG_OOB message and\nqueue_oob() can update unix_sk(sk)-\u0026gt;oob_skb concurrently, leading\nNULL pointer dereference. [0]\r\n\r\nTo fix the issue, let\u0026apos;s update unix_sk(sk)-\u0026gt;oob_skb under the\nsk_receive_queue\u0026apos;s lock and take it everywhere we touch oob_skb.\r\n\r\nNote that we defer kfree_skb() in manage_oob() to silence lockdep\nfalse-positive (See [1]).\r\n\r\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PF: supervisor write access in kernel mode\n PF: error_code(0x0002) - not-present page\nPGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0\nOops: 0002 [#1] PREEMPT SMP PTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events delayed_fput\nRIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847)\nCode: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 \u0026lt;48\u0026gt; 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc\nRSP: 0018:ffffc900001bfd48 EFLAGS: 00000002\nRAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9\nRDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00\nRBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00\nR13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80\nFS:  0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unix_release_sock (net/unix/af_unix.c:654)\n unix_release (net/unix/af_unix.c:1050)\n __sock_release (net/socket.c:660)\n sock_close (net/socket.c:1423)\n __fput (fs/file_table.c:423)\n delayed_fput (fs/file_table.c:444 (discriminator 3))\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416)\n kthread (kernel/kthread.c:388)\n ret_from_fork (arch/x86/kernel/process.c:153)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:257)\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 0000000000000008(CVE-2024-36972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: do not leave a dangling sk pointer, when socket creation fails\r\n\r\nIt is possible to trigger a use-after-free by:\n  * attaching an fentry probe to __sock_release() and the probe calling the\n    bpf_get_socket_cookie() helper\n  * running traceroute -I 1.1.1.1 on a freshly booted VM\r\n\r\nA KASAN enabled kernel will log something like below (decoded and stripped):\n==================================================================\nBUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)\nRead of size 8 at addr ffff888007110dd8 by task traceroute/299\r\n\r\nCPU: 2 PID: 299 Comm: traceroute Tainted: G            E      6.10.0-rc2+ #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))\nprint_report (mm/kasan/report.c:378 mm/kasan/report.c:488)\n? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)\nkasan_report (mm/kasan/report.c:603)\n? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)\nkasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189)\n__sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)\nbpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092)\nbpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e\nbpf_trampoline_6442506592+0x47/0xaf\n__sock_release (net/socket.c:652)\n__sock_create (net/socket.c:1601)\n...\nAllocated by task 299 on cpu 2 at 78.328492s:\nkasan_save_stack (mm/kasan/common.c:48)\nkasan_save_track (mm/kasan/common.c:68)\n__kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)\nkmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007)\nsk_prot_alloc (net/core/sock.c:2075)\nsk_alloc (net/core/sock.c:2134)\ninet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252)\n__sock_create (net/socket.c:1572)\n__sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)\n__x64_sys_socket (net/socket.c:1718)\ndo_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nFreed by task 299 on cpu 2 at 78.328502s:\nkasan_save_stack (mm/kasan/common.c:48)\nkasan_save_track (mm/kasan/common.c:68)\nkasan_save_free_info (mm/kasan/generic.c:582)\npoison_slab_object (mm/kasan/common.c:242)\n__kasan_slab_free (mm/kasan/common.c:256)\nkmem_cache_free (mm/slub.c:4437 mm/slub.c:4511)\n__sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208)\ninet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252)\n__sock_create (net/socket.c:1572)\n__sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)\n__x64_sys_socket (net/socket.c:1718)\ndo_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nFix this by clearing the struct socket reference in sk_common_release() to cover\nall protocol families create functions, which may already attached the\nreference to the sk object with sock_init_data().(CVE-2024-40954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetns: Make get_net_ns() handle zero refcount net\r\n\r\nSyzkaller hit a warning:\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0\nModules linked in:\nCPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xdf/0x1d0\nCode: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 \u0026lt;0f\u0026gt; 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1\nRSP: 0018:ffff8881067b7da0 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac\nRDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001\nRBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139\nR10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4\nR13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040\nFS:  00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0xa3/0xc0\n ? __warn+0xa5/0x1c0\n ? refcount_warn_saturate+0xdf/0x1d0\n ? report_bug+0x1fc/0x2d0\n ? refcount_warn_saturate+0xdf/0x1d0\n ? handle_bug+0xa1/0x110\n ? exc_invalid_op+0x3c/0xb0\n ? asm_exc_invalid_op+0x1f/0x30\n ? __warn_printk+0xcc/0x140\n ? __warn_printk+0xd5/0x140\n ? refcount_warn_saturate+0xdf/0x1d0\n get_net_ns+0xa4/0xc0\n ? __pfx_get_net_ns+0x10/0x10\n open_related_ns+0x5a/0x130\n __tun_chr_ioctl+0x1616/0x2370\n ? __sanitizer_cov_trace_switch+0x58/0xa0\n ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30\n ? __pfx_tun_chr_ioctl+0x10/0x10\n tun_chr_ioctl+0x2f/0x40\n __x64_sys_ioctl+0x11b/0x160\n x64_sys_call+0x1211/0x20d0\n do_syscall_64+0x9e/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f5b28f165d7\nCode: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8\nRSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7\nRDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003\nRBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0\nR10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730\nR13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\nKernel panic - not syncing: kernel: panic_on_warn set ...\r\n\r\nThis is trigger as below:\n          ns0                                    ns1\ntun_set_iff() //dev is tun0\n   tun-\u0026gt;dev = dev\n//ip link set tun0 netns ns1\n                                       put_net() //ref is 0\n__tun_chr_ioctl() //TUNGETDEVNETNS\n   net = dev_net(tun-\u0026gt;dev);\n   open_related_ns(\u0026amp;net-\u0026gt;ns, get_net_ns); //ns1\n     get_net_ns()\n        get_net() //addition on 0\r\n\r\nUse maybe_get_net() in get_net_ns in case net\u0026apos;s ref is zero to fix this(CVE-2024-40958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie()\r\n\r\nWe got the following issue in our fault injection stress test:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600\nRead of size 8 at addr ffff888118efc000 by task kworker/u78:0/109\r\n\r\nCPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kasan_report+0x93/0xc0\n cachefiles_withdraw_cookie+0x4d9/0x600\n fscache_cookie_state_machine+0x5c8/0x1230\n fscache_cookie_worker+0x91/0x1c0\n process_one_work+0x7fa/0x1800\n [...]\r\n\r\nAllocated by task 117:\n kmalloc_trace+0x1b3/0x3c0\n cachefiles_acquire_volume+0xf3/0x9c0\n fscache_create_volume_work+0x97/0x150\n process_one_work+0x7fa/0x1800\n [...]\r\n\r\nFreed by task 120301:\n kfree+0xf1/0x2c0\n cachefiles_withdraw_cache+0x3fa/0x920\n cachefiles_put_unbind_pincount+0x1f6/0x250\n cachefiles_daemon_release+0x13b/0x290\n __fput+0x204/0xa00\n task_work_run+0x139/0x230\n do_exit+0x87a/0x29b0\n [...]\n==================================================================\r\n\r\nFollowing is the process that triggers the issue:\r\n\r\n           p1                |             p2\n------------------------------------------------------------\n                              fscache_begin_lookup\n                               fscache_begin_volume_access\n                                fscache_cache_is_live(fscache_cache)\ncachefiles_daemon_release\n cachefiles_put_unbind_pincount\n  cachefiles_daemon_unbind\n   cachefiles_withdraw_cache\n    fscache_withdraw_cache\n     fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN);\n    cachefiles_withdraw_objects(cache)\n    fscache_wait_for_objects(fscache)\n      atomic_read(\u0026amp;fscache_cache-\u0026gt;object_count) == 0\n                              fscache_perform_lookup\n                               cachefiles_lookup_cookie\n                                cachefiles_alloc_object\n                                 refcount_set(\u0026amp;object-\u0026gt;ref, 1);\n                                 object-\u0026gt;volume = volume\n                                 fscache_count_object(vcookie-\u0026gt;cache);\n                                  atomic_inc(\u0026amp;fscache_cache-\u0026gt;object_count)\n    cachefiles_withdraw_volumes\n     cachefiles_withdraw_volume\n      fscache_withdraw_volume\n      __cachefiles_free_volume\n       kfree(cachefiles_volume)\n                              fscache_cookie_state_machine\n                               cachefiles_withdraw_cookie\n                                cache = object-\u0026gt;volume-\u0026gt;cache;\n                                // cachefiles_volume UAF !!!\r\n\r\nAfter setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups\nto complete first, and then wait for fscache_cache-\u0026gt;object_count == 0 to\navoid the cookie exiting after the volume has been freed and triggering\nthe above issue. Therefore call fscache_withdraw_volume() before calling\ncachefiles_withdraw_objects().\r\n\r\nThis way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two\ncases will occur:\n1) fscache_begin_lookup fails in fscache_begin_volume_access().\n2) fscache_withdraw_volume() will ensure that fscache_count_object() has\n   been executed before calling fscache_wait_for_objects().(CVE-2024-41057)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpi3mr: Sanitise num_phys\r\n\r\nInformation is stored in mr_sas_port-\u0026gt;phy_mask, values larger then size of\nthis field shouldn\u0026apos;t be allowed.(CVE-2024-42159)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvhost/vsock: always initialize seqpacket_allow\r\n\r\nThere are two issues around seqpacket_allow:\n1. seqpacket_allow is not initialized when socket is\n   created. Thus if features are never set, it will be\n   read uninitialized.\n2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,\n   then seqpacket_allow will not be cleared appropriately\n   (existing apps I know about don\u0026apos;t usually do this but\n    it\u0026apos;s legal and there\u0026apos;s no way to be sure no one relies\n    on this).\r\n\r\nTo fix:\n\t- initialize seqpacket_allow after allocation\n\t- set it unconditionally in set_features(CVE-2024-43873)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Validate TA binary size\r\n\r\nAdd TA binary size validation to avoid OOB write.\r\n\r\n(cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)(CVE-2024-44977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: flowtable: validate vlan header\r\n\r\nEnsure there is sufficient room to access the protocol field of the\nVLAN header, validate it once before the flowtable lookup.\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32\n nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626\n nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]\n nf_ingress net/core/dev.c:5440 [inline](CVE-2024-44983)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natm: idt77252: prevent use after free in dequeue_rx()\r\n\r\nWe can\u0026apos;t dereference \u0026quot;skb\u0026quot; after calling vcc-\u0026gt;push() because the skb\nis released.(CVE-2024-44998)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: amd_sfh: free driver_data after destroying hid device\r\n\r\nHID driver callbacks aren\u0026apos;t called anymore once hid_destroy_device() has\nbeen called. Hence, hid driver_data should be freed only after the\nhid_destroy_device() function returned as driver_data is used in several\ncallbacks.\r\n\r\nI observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling\nKASAN to debug memory allocation, I got this output:\r\n\r\n  [   13.050438] ==================================================================\n  [   13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]\n  [   13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3\n  [   13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479\r\n\r\n  [   13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0\n  [   13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024\n  [   13.067860] Call Trace:\n  [   13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8\n  [   13.071486]  \u0026lt;TASK\u0026gt;\n  [   13.071492]  dump_stack_lvl+0x5d/0x80\n  [   13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -\u0026gt; 0002)\n  [   13.078296]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.082199]  print_report+0x174/0x505\n  [   13.085776]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n  [   13.089367]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.093255]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.097464]  kasan_report+0xc8/0x150\n  [   13.101461]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.105802]  amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.110303]  amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.114879]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.119450]  sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]\n  [   13.124097]  hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]\n  [   13.127404]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.131925]  ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]\n  [   13.136455]  ? _raw_spin_lock_irqsave+0x96/0xf0\n  [   13.140197]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n  [   13.143602]  ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]\n  [   13.147234]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.150446]  ? __devm_add_action+0x167/0x1d0\n  [   13.155061]  hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]\n  [   13.158581]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.161814]  platform_probe+0xa2/0x150\n  [   13.165029]  really_probe+0x1e3/0x8a0\n  [   13.168243]  __driver_probe_device+0x18c/0x370\n  [   13.171500]  driver_probe_device+0x4a/0x120\n  [   13.175000]  __driver_attach+0x190/0x4a0\n  [   13.178521]  ? __pfx___driver_attach+0x10/0x10\n  [   13.181771]  bus_for_each_dev+0x106/0x180\n  [   13.185033]  ? __pfx__raw_spin_lock+0x10/0x10\n  [   13.188229]  ? __pfx_bus_for_each_dev+0x10/0x10\n  [   13.191446]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.194382]  bus_add_driver+0x29e/0x4d0\n  [   13.197328]  driver_register+0x1a5/0x360\n  [   13.200283]  ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]\n  [   13.203362]  do_one_initcall+0xa7/0x380\n  [   13.206432]  ? __pfx_do_one_initcall+0x10/0x10\n  [   13.210175]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.213211]  ? kasan_unpoison+0x44/0x70\n  [   13.216688]  do_init_module+0x238/0x750\n  [   13.2196\n---truncated---(CVE-2024-46746)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Fix double free in OPTEE transport  Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.(CVE-2024-49853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors  x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove().  When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.(CVE-2024-49986)\r\n\r\n(CVE-2024-50121)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: SCO: Fix UAF on sco_sock_timeout  conn-\u0026gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn-\u0026gt;sk is still valid by checking if it part of sco_sk_list.(CVE-2024-50125)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  dm cache: fix flushing uninitialized delayed_work on cache_ctr error  An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error.  Reproduce steps:  dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot; dmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot; dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;  Kernel logs:  (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890  Fix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s error path. This patch doesn\u0026apos;t affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix UAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: dwc3: fix fault at system suspend if device was already runtime suspended  If the device was already runtime suspended then during system suspend we cannot access the device registers else it will crash.  Also we cannot access any registers after dwc3_core_exit() on some platforms so move the dwc3_enable_susphy() call to the top.(CVE-2024-53070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: Fix use-after-free of network namespace.  Recently, we got a customer report that CIFS triggers oops while reconnecting to a server.  [0]  The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces.  The problem rarely happened, but it was always while the pod was dying.  The root cause is wrong reference counting for network namespace.  CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to.  That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.  The repro steps are roughly:    1. mount CIFS in a non-root netns   2. drop packets from the netns   3. destroy the netns   4. unmount CIFS  We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.  When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.  Let\u0026apos;s hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\u0026quot;smc: Fix use-after-free in tcp_write_timer_handler().\u0026quot;).  Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().  Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.  [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info:   ESR = 0x0000000096000004   EC = 0x25: DABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x04: level 0 translation fault Data abort info:   ISV = 0, ISS = 0x00000004   CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace:  fib_rules_lookup+0x44/0x238  __fib_lookup+0x64/0xbc  ip_route_output_key_hash_rcu+0x2c4/0x398  ip_route_output_key_hash+0x60/0x8c  tcp_v4_connect+0x290/0x488  __inet_stream_connect+0x108/0x3d0  inet_stream_connect+0x50/0x78  kernel_connect+0x6c/0xac  generic_ip_conne ---truncated---(CVE-2024-53095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Adjust VSDB parser for replay feature  At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN:  [   27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [   27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383  ...  [   27.821207] Memory state around the buggy address: [   27.821215]  ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [   27.821224]  ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [   27.821234] \u0026gt;ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [   27.821243]                    ^ [   27.821250]  ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [   27.821259]  ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [   27.821268] ==================================================================  This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size.  (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)(CVE-2024-53108)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/rockchip: vop: Fix a dereferenced before check warning  The \u0026apos;state\u0026apos; can\u0026apos;t be NULL, we should check crtc_state.  Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check \u0026apos;state\u0026apos; (see line 1077)(CVE-2024-53129)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  initramfs: avoid filename buffer overrun  The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as:   37 cpio_file := ALGN(4) + cpio_header + filename + \u0026quot;\\0\u0026quot; + ALGN(4) + data ...  55 ============= ================== =========================  56 Field name    Field size         Meaning  57 ============= ================== ========================= ...  70 c_namesize    8 bytes            Length of filename, including final \\0  When extracting an initramfs cpio archive, the kernel\u0026apos;s do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod().  If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn\u0026apos;t be considered a security vulnerability.  Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g.   ./reproducer.sh | gzip \u0026gt;\u0026gt; /myinitramfs  It\u0026apos;s easiest to observe non-zero uninitialized memory when the output is gzipped, as it\u0026apos;ll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block.  ---- reproducer.sh ---- nilchar=\u0026quot;A\u0026quot; # change to \u0026quot;\\0\u0026quot; to properly zero terminate / pad magic=\u0026quot;070701\u0026quot; ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\u0026quot;initramfs_test_fname_overrun\u0026quot; namelen=$(( ${#fname} + 1 )) # plus one to account for terminator  printf \u0026quot;%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\u0026quot; \\  $magic $ino $mode $uid $gid $nlink $mtime $filesize \\  $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname  termpadlen=$(( 1 + ((4 - ((110 + $namelen) \u0026amp; 3)) % 4) )) printf \u0026quot;%.s${nilchar}\u0026quot; $(seq 1 $termpadlen) ---- reproducer.sh ----  Symlink filename fields handled in do_symlink() won\u0026apos;t overrun past the data segment, due to the explicit zero-termination of the symlink target.  Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn\u0026apos;t carry a zero-terminator at the expected (name_len - 1) offset.(CVE-2024-53142)",
  "id": "OESA-2024-2590",
  "modified": "2026-08-06T11:08:04Z",
  "published": "2024-12-27T11:08:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41057"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42159"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43873"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44977"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44983"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46746"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49853"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49986"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50121"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50280"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53070"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53108"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53129"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53142"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-36972",
    "CVE-2024-40954",
    "CVE-2024-40958",
    "CVE-2024-41057",
    "CVE-2024-42159",
    "CVE-2024-43873",
    "CVE-2024-44977",
    "CVE-2024-44983",
    "CVE-2024-44998",
    "CVE-2024-46746",
    "CVE-2024-49853",
    "CVE-2024-49986",
    "CVE-2024-50121",
    "CVE-2024-50125",
    "CVE-2024-50280",
    "CVE-2024-53070",
    "CVE-2024-53095",
    "CVE-2024-53108",
    "CVE-2024-53129",
    "CVE-2024-53142"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-248.0.0.150.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-248.0.0.150.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix race condition between session lookup and expire\n\n Thread A                        +  Thread B\n ksmbd_session_lookup            |  smb2_sess_setup\n   sess = xa_load                |\n                                 |\n                                 |    xa_erase(\u0026amp;conn-\u0026gt;sessions, sess-\u0026gt;id);\n                                 |\n                                 |    ksmbd_session_destroy(sess) --\u0026gt; kfree(sess)\n                                 |\n   // UAF!                       |\n   sess-\u0026gt;last_active = jiffies   |\n                                 +\n\nThis patch add rwsem to fix race condition between ksmbd_session_lookup\nand ksmbd_expire_session.(CVE-2023-52480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Fix connection failure handling\n\nIn case immediate MPA request processing fails, the newly\ncreated endpoint unlinks the listening endpoint and is\nready to be dropped. This special case was not handled\ncorrectly by the code handling the later TCP socket close,\ncausing a NULL dereference crash in siw_cm_work_handler()\nwhen dereferencing a NULL listener. We now also cancel\nthe useless MPA timeout, if immediate MPA request\nprocessing fails.\n\nThis patch furthermore simplifies MPA processing in general:\nScheduling a useless TCP socket read in sk_data_ready() upcall\nis now surpressed, if the socket is already moved out of\nTCP_ESTABLISHED state.(CVE-2023-52513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix buffer overflow in trans_stat_show\n\nFix buffer overflow in trans_stat_show().\n\nConvert simple snprintf to the more secure scnprintf with size of\nPAGE_SIZE.\n\nAdd condition checking if we are exceeding PAGE_SIZE and exit early from\nloop. Also add at the end a warning that we exceeded PAGE_SIZE and that\nstats is disabled.\n\nReturn -EFBIG in the case where we don\u0026apos;t have enough space to write the\nfull transition table.\n\nAlso document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7091r: Allow users to configure device events\n\nAD7091R-5 devices are supported by the ad7091r-5 driver together with\nthe ad7091r-base driver. Those drivers declared iio events for notifying\nuser space when ADC readings fall bellow the thresholds of low limit\nregisters or above the values set in high limit registers.\nHowever, to configure iio events and their thresholds, a set of callback\nfunctions must be implemented and those were not present until now.\nThe consequence of trying to configure ad7091r-5 events without the\nproper callback functions was a null pointer dereference in the kernel\nbecause the pointers to the callback functions were not set.\n\nImplement event configuration callbacks allowing users to read/write\nevent thresholds and enable/disable event generation.\n\nSince the event spec structs are generic to AD7091R devices, also move\nthose from the ad7091r-5 driver the base driver so they can be reused\nwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential context UAFs\n\ngem_context_register() makes the context visible to userspace, and which\npoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.\nSo we need to ensure that nothing uses the ctx ptr after this.  And we\nneed to ensure that adding the ctx to the xarray is the *last* thing\nthat gem_context_register() does with the ctx pointer.\n\n[tursulin: Stable and fixes tags add/tidy.]\n(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: handle isoc Babble and Buffer Overrun events properly\n\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\n\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n\u0026quot;Transfer event TRB DMA ptr not part of current TD\u0026quot; error message.\n\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\n\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Fix out-of-bounds memory access\n\nFix a bug that pdata-\u0026gt;cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.(CVE-2024-26664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations\n\n- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.\n- Disallow layer 4 protocol with no ports, since destination port is a\n  mandatory attribute for this object.(CVE-2024-26673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: roles: fix NULL pointer issue when put module\u0026apos;s reference\n\nIn current design, usb role class driver will get usb_role_switch parent\u0026apos;s\nmodule reference after the user get usb_role_switch device and put the\nreference after the user put the usb_role_switch device. However, the\nparent device of usb_role_switch may be removed before the user put the\nusb_role_switch. If so, then, NULL pointer issue will be met when the user\nput the parent module\u0026apos;s reference.\n\nThis will save the module pointer in structure of usb_role_switch. Then,\nwe don\u0026apos;t need to find module by iterating long relations.(CVE-2024-26747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829  if (request-\u0026gt;complete) {\n830          spin_unlock(\u0026amp;priv_dev-\u0026gt;lock);\n831          usb_gadget_giveback_request(\u0026amp;priv_ep-\u0026gt;endpoint,\n832                                    request);\n833          spin_lock(\u0026amp;priv_dev-\u0026gt;lock);\n834  }\n835\n836  if (request-\u0026gt;buf == priv_dev-\u0026gt;zlp_buf)\n837      cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][  T150]\n[ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0026apos;t call\nusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()\n\n  ...\n  cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, \u0026amp;priv_req-\u0026gt;request);\n  list_del_init(\u0026amp;priv_req-\u0026gt;list);\n  ...\n\n\u0026apos;priv_req\u0026apos; actually free at cdns3_gadget_ep_free_request(). But\nlist_del_init() use priv_req-\u0026gt;list after it.\n\n[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4\n[ 1542.642868][  T534]\n[ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):\n[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4\n[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]\n[ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4\n[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8\n[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368\n[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28\n\nMove list_del_init() before cdns3_gadget_ep_free_request() to resolve this\nproblem.(CVE-2024-26749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio/akcipher - Fix stack overflow on memcpy\n\nsizeof(struct virtio_crypto_akcipher_session_para) is less than\nsizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from\nstack variable leads stack overflow. Clang reports this issue by\ncommands:\nmake -j CC=clang-14 mrproper \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build CC=clang-14 allmodconfig \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/\n  virtio_crypto_akcipher_algs.o(CVE-2024-26753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix possible deadlock in subflow diag\n\nSyzbot and Eric reported a lockdep splat in the subflow diag:\n\n   WARNING: possible circular locking dependency detected\n   6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted\n\n   syz-executor.2/24141 is trying to acquire lock:\n   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n\n   but task is already holding lock:\n   ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock\n   include/linux/spinlock.h:351 [inline]\n   ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at:\n   inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038\n\n   which lock already depends on the new lock.\n\n   the existing dependency chain (in reverse order) is:\n\n   -\u0026gt; #1 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}:\n   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n   _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154\n   spin_lock include/linux/spinlock.h:351 [inline]\n   __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743\n   inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261\n   __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217\n   inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239\n   rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316\n   rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577\n   ops_init+0x352/0x610 net/core/net_namespace.c:136\n   __register_pernet_operations net/core/net_namespace.c:1214 [inline]\n   register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283\n   register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370\n   rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735\n   do_one_initcall+0x238/0x830 init/main.c:1236\n   do_initcall_level+0x157/0x210 init/main.c:1298\n   do_initcalls+0x3f/0x80 init/main.c:1314\n   kernel_init_freeable+0x42f/0x5d0 init/main.c:1551\n   kernel_init+0x1d/0x2a0 init/main.c:1441\n   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n   ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n\n   -\u0026gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:\n   check_prev_add kernel/locking/lockdep.c:3134 [inline]\n   check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n   validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n   __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n   lock_sock_fast include/net/sock.h:1723 [inline]\n   subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28\n   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n   inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345\n   inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061\n   __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263\n   inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371\n   netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264\n   __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370\n   netlink_dump_start include/linux/netlink.h:338 [inline]\n   inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405\n   sock_diag_rcv_msg+0xe7/0x410\n   netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n   sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n   netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n   netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n   netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n   sock_sendmsg_nosec net/socket.c:730 [inline]\n   __sock_sendmsg+0x221/0x270 net/socket.c:745\n   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n   ___sys_sendmsg net/socket.c:2638 [inline]\n   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n   do_syscall_64+0xf9/0x240\n   entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nAs noted by Eric we can break the lock dependency chain avoid\ndumping \n---truncated---(CVE-2024-26781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.(CVE-2024-26790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS:  00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985]  ? __die_body.cold+0x1a/0x1f\n[ 1010.715995]  ? die_addr+0x43/0x70\n[ 1010.716002]  ? exc_general_protection+0x199/0x2f0\n[ 1010.716016]  ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026]  ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034]  ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042]  __rtnl_newlink+0x1063/0x1700\n[ 1010.716051]  ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063]  ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070]  ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076]  ? __kernel_text_address+0x56/0xa0\n[ 1010.716084]  ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091]  ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098]  ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106]  ? stack_trace_save+0x91/0xd0\n[ 1010.716113]  ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121]  ? __lock_acquire+0x15c5/0x5380\n[ 1010.716139]  ? mark_held_locks+0x9e/0xe0\n[ 1010.716148]  ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155]  ? __rtnl_newlink+0x1700/0x1700\n[ 1010.716160]  rtnl_newlink+0x69/0xa0\n[ 1010.716166]  rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172]  ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179]  ? lock_acquire+0x1fe/0x560\n[ 1010.716188]  ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196]  netlink_rcv_skb+0x14d/0x440\n[ 1010.716202]  ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208]  ? netlink_ack+0xab0/0xab0\n[ 1010.716213]  ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220]  ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226]  ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233]  netlink_unicast+0x54b/0x800\n[ 1010.716240]  ? netlink_attachskb+0x870/0x870\n[ 1010.716248]  ? __check_object_size+0x2de/0x3b0\n[ 1010.716254]  netlink_sendmsg+0x938/0xe40\n[ 1010.716261]  ? netlink_unicast+0x800/0x800\n[ 1010.716269]  ? __import_iovec+0x292/0x510\n[ 1010.716276]  ? netlink_unicast+0x800/0x800\n[ 1010.716284]  __sock_sendmsg+0x159/0x190\n[ 1010.716290]  ____sys_sendmsg+0x712/0x880\n[ 1010.716297]  ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304]  ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309]  ? lock_acquire+0x1fe/0x560\n[ 1010.716315]  ? drain_array_locked+0x90/0x90\n[ 1010.716324]  ___sys_sendmsg+0xf8/0x170\n[ 1010.716331]  ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337]  ? lockdep_init_map\n---truncated---(CVE-2024-26793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  rpm_resume+0xe0/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  clk_pm_runtime_get+0x30/0xb0\n  clk_disable_unused_subtree+0x58/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused+0x4c/0xe4\n  do_one_initcall+0xcc/0x2d8\n  do_initcall_level+0xa4/0x148\n  do_initcalls+0x5c/0x9c\n  do_basic_setup+0x24/0x30\n  kernel_init_freeable+0xec/0x164\n  kernel_init+0x28/0x120\n  ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  schedule_preempt_disabled+0x2c/0x48\n  __mutex_lock+0x238/0x488\n  __mutex_lock_slowpath+0x1c/0x28\n  mutex_lock+0x50/0x74\n  clk_prepare_lock+0x7c/0x9c\n  clk_core_prepare_lock+0x20/0x44\n  clk_prepare+0x24/0x30\n  clk_bulk_prepare+0x40/0xb0\n  mdss_runtime_resume+0x54/0x1c8\n  pm_generic_runtime_resume+0x30/0x44\n  __genpd_runtime_resume+0x68/0x7c\n  genpd_runtime_resume+0x108/0x1f4\n  __rpm_callback+0x84/0x144\n  rpm_callback+0x30/0x88\n  rpm_resume+0x1f4/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  __device_attach+0xe0/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  device_add+0x644/0x814\n  mipi_dsi_device_register_full+0xe4/0x170\n  devm_mipi_dsi_device_register_full+0x28/0x70\n  ti_sn_bridge_probe+0x1dc/0x2c0\n  auxiliary_bus_probe+0x4c/0x94\n  really_probe+0xcc/0x2c8\n  __driver_probe_device+0xa8/0x130\n  driver_probe_device+0x48/0x110\n  __device_attach_driver+0xa4/0xcc\n  bus_for_each_drv+0x8c/0xd8\n  __device_attach+0xf8/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  deferred_probe_work_func+0x9c/0xd8\n  process_one_work+0x148/0x518\n  worker_thread+0x138/0x350\n  kthread+0x138/0x1e0\n  ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0026apos;ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0026apos;re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0026apos;t have the chance to\nschedule away with the prepare_lock held. Let\u0026apos;s fix this immediate\nproblem that can be\n---truncated---(CVE-2024-27004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: relax socket state check at accept time.\n\nChristoph reported the following splat:\n\nWARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0\nModules linked in:\nCPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759\nCode: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd \u0026lt;0f\u0026gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80\nRSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293\nRAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64\nR10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000\nR13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800\nFS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786\n do_accept+0x435/0x620 net/socket.c:1929\n __sys_accept4_file net/socket.c:1969 [inline]\n __sys_accept4+0x9b/0x110 net/socket.c:1999\n __do_sys_accept net/socket.c:2016 [inline]\n __se_sys_accept net/socket.c:2013 [inline]\n __x64_sys_accept+0x7d/0x90 net/socket.c:2013\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x4315f9\nCode: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00\nRSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300\nR10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055\n \u0026lt;/TASK\u0026gt;\n\nThe reproducer invokes shutdown() before entering the listener status.\nAfter commit 94062790aedb (\u0026quot;tcp: defer shutdown(SEND_SHUTDOWN) for\nTCP_SYN_RECV sockets\u0026quot;), the above causes the child to reach the accept\nsyscall in FIN_WAIT1 status.\n\nEric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn\u0026apos;t\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel\u0026apos;s native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n  safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n  instruction out-of-line when that instruction cannot be stepped\n  out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n  interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn\u0026apos;t caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n  the compiler and sparse have no idea these contain a little-endian\n  32-bit value. The core uprobes code populates these with a memcpy()\n  which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n  to the similarly-named probe_opcode_t, which is an alias for u32.\n  Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include \u0026lt;stdio.h\u0026gt;\n| #include \u0026lt;stdbool.h\u0026gt;\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n|         void *addr;\n|\n|         asm volatile(\n|         \u0026quot;       adrp    %x0, adrp_self\\n\u0026quot;\n|         \u0026quot;       add     %x0, %x0, :lo12:adrp_self\\n\u0026quot;\n|         : \u0026quot;=r\u0026quot; (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n|         void *ptr = adrp_self();\n|         bool equal = (ptr == adrp_self);\n|\n|         printf(\u0026quot;adrp_self   =\u0026gt; %p\\n\u0026quot;\n|                \u0026quot;adrp_self() =\u0026gt; %p\\n\u0026quot;\n|                \u0026quot;%s\\n\u0026quot;,\n|                adrp_self, ptr, equal ? \u0026quot;EQUAL\u0026quot; : \u0026quot;NOT EQUAL\u0026quot;);\n|\n|         return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 \u0026lt;adrp_self\u0026gt;:\n|   4007e0:       90000000        adrp    x0, 400000 \u0026lt;__ehdr_start\u0026gt;\n|   4007e4:       911f8000        add     x0, x0, #0x7e0\n|   4007e8:       d65f03c0        ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| #\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL(CVE-2024-50194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix flushing uninitialized delayed_work on cache_ctr error\n\nAn unexpected WARN_ON from flush_work() may occur when cache creation\nfails, caused by destroying the uninitialized delayed_work waker in the\nerror path of cache_create(). For example, the warning appears on the\nsuperblock checksum error.\n\nReproduce steps:\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\nWARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890\n\nFix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s\nerror path. This patch doesn\u0026apos;t affect the use-after-free fix for\nconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix\nUAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure.  In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: net: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the uml_net instance. Otherwise, removing a network device will\nresult in a crash:\n\nRIP: 0033:net_device_release+0x10/0x6f\nRSP: 00000000e20c7c40  EFLAGS: 00010206\nRAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0\nRDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028\nRBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70\nR10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000\nR13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 627af028 62c7af00 e20c7c80 60276fcd\n 62778000 603f5820 627af028 00000000\n e20c7cb0 603a2bcd 627af000 62770010\nCall Trace:\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;6002ec9c\u0026gt;] net_remove+0x63/0x69\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;60087d40\u0026gt;] ? __remove_hrtimer+0x38/0x74\n [\u0026lt;60087ff8\u0026gt;] ? hrtimer_try_to_cancel+0x8c/0x98\n [\u0026lt;6006b3cf\u0026gt;] ? dl_server_stop+0x3f/0x48\n [\u0026lt;6006b390\u0026gt;] ? dl_server_stop+0x0/0x48\n [\u0026lt;600672e8\u0026gt;] ? dequeue_entities+0x327/0x390\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[  356.775250] ------------[ cut here ]------------\n[  356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n    ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n    [...]\n    memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n           user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Require entities to have a non-zero unique ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nSo, deny allocating an entity with ID 0 or an ID that belongs to a unit\nthat is already added to the list of entities.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[   20.830206] usb 1-1: Using ep0 maxpacket: 8\n[   20.833501] usb 1-1: config 0 descriptor??\n[   21.038518] usb 1-1: string descriptor 0 read error: -71\n[   21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[   21.042218] ------------[ cut here ]------------\n[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[   21.043195] Modules linked in:\n[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[   21.044639] Workqueue: usb_hub_wq hub_event\n[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[   21.051136] PKRU: 55555554\n[   21.051331] Call Trace:\n[   21.051480]  \u0026lt;TASK\u0026gt;\n[   21.051611]  ? __warn+0xc4/0x210\n[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.052252]  ? report_bug+0x11b/0x1a0\n[   21.052540]  ? trace_hardirqs_on+0x31/0x40\n[   21.052901]  ? handle_bug+0x3d/0x70\n[   21.053197]  ? exc_invalid_op+0x1a/0x50\n[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20\n[   21.053924]  ? media_create_pad_link+0x91/0x2e0\n[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.054834]  ? media_create_pad_link+0x91/0x2e0\n[   21.055131]  ? _raw_spin_unlock+0x1e/0x40\n[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210\n[   21.055837]  uvc_mc_register_entities+0x358/0x400\n[   21.056144]  uvc_register_chains+0x1fd/0x290\n[   21.056413]  uvc_probe+0x380e/0x3dc0\n[   21.056676]  ? __lock_acquire+0x5aa/0x26e0\n[   21.056946]  ? find_held_lock+0x33/0xa0\n[   21.057196]  ? kernfs_activate+0x70/0x80\n[   21.057533]  ? usb_match_dy\n---truncated---(CVE-2024-56571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855]   ESR = 0x0000000096000004\n[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125]   SET = 0, FnV = 0\n[67840.878291]   EA = 0, S1PTW = 0\n[67840.881545]   FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456]  down_write+0x30/0x98\n[67841.096017]  start_creating.part.0+0x60/0x198\n[67841.100613]  debugfs_create_dir+0x48/0x1f8\n[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115]  full_proxy_write+0x68/0xc8\n[67841.129175]  vfs_write+0xd8/0x3f0\n[67841.132708]  ksys_write+0x70/0x108\n[67841.136317]  __arm64_sys_write+0x24/0x38\n[67841.140440]  invoke_syscall+0x50/0x128\n[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273]  do_el0_svc+0x24/0x38\n[67841.152773]  el0_svc+0x38/0xd8\n[67841.156009]  el0t_64_sync_handler+0xc0/0xc8\n[67841.160361]  el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last  enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last  enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n|  \u0026lt;IRQ\u0026gt;\n|  dump_stack_lvl+0x7e/0xc0\n|  dump_stack+0x1d/0x30\n|  __might_resched+0x1a2/0x270\n|  rt_spin_lock+0x68/0x170\n|  kcsan_skip_report_debugfs+0x43/0xe0\n|  print_report+0xb5/0x590\n|  kcsan_report_known_origin+0x1b1/0x1d0\n|  kcsan_setup_watchpoint+0x348/0x650\n|  __tsan_unaligned_write1+0x16d/0x1d0\n|  hrtimer_interrupt+0x3d6/0x430\n|  __sysvec_apic_timer_interrupt+0xe8/0x3a0\n|  sysvec_apic_timer_interrupt+0x97/0xc0\n|  \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM\n\nWe currently assume that there is at least one VMA in a MM, which isn\u0026apos;t\ntrue.\n\nSo we might end up having find_vma() return NULL, to then de-reference\nNULL.  So properly handle find_vma() returning NULL.\n\nThis fixes the report:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nRIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]\nRIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194\nCode: ...\nRSP: 0018:ffffc9000375fd08 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000\nRDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044\nRBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1\nR10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003\nR13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8\nFS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709\n __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]\n __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]\n __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022]  ? __dentry_kill+0x121/0x170\n[596663.813030]  ? _cond_resched+0x15/0x30\n[596663.813034]  ? _cond_resched+0x15/0x30\n[596663.813039]  ? wait_for_completion+0x35/0x190\n[596663.813048]  ? try_to_wake_up+0x63/0x540\n[596663.813055]  free_task+0x5a/0x60\n[596663.813061]  kthread_stop+0xf3/0x100\n[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota.  Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed.  Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)",
  "id": "OESA-2025-1095",
  "modified": "2026-08-06T11:08:11Z",
  "published": "2025-02-08T11:08:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52480"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52513"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52627"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26790"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26793"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36484"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50280"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53131"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56571"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56610"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56611"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56715"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2023-52480",
    "CVE-2023-52513",
    "CVE-2023-52614",
    "CVE-2023-52627",
    "CVE-2023-52913",
    "CVE-2024-24857",
    "CVE-2024-24859",
    "CVE-2024-26659",
    "CVE-2024-26664",
    "CVE-2024-26673",
    "CVE-2024-26747",
    "CVE-2024-26748",
    "CVE-2024-26749",
    "CVE-2024-26753",
    "CVE-2024-26781",
    "CVE-2024-26790",
    "CVE-2024-26793",
    "CVE-2024-26952",
    "CVE-2024-27004",
    "CVE-2024-36479",
    "CVE-2024-36484",
    "CVE-2024-37021",
    "CVE-2024-40965",
    "CVE-2024-50194",
    "CVE-2024-50280",
    "CVE-2024-53131",
    "CVE-2024-53183",
    "CVE-2024-53198",
    "CVE-2024-53201",
    "CVE-2024-56539",
    "CVE-2024-56571",
    "CVE-2024-56588",
    "CVE-2024-56610",
    "CVE-2024-56611",
    "CVE-2024-56623",
    "CVE-2024-56688",
    "CVE-2024-56704",
    "CVE-2024-56715",
    "CVE-2024-56746",
    "CVE-2024-57892"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-248.0.0.147.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-248.0.0.147.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential OOBs in smb2_parse_contexts()\n\nValidate offsets and lengths before dereferencing create contexts in\nsmb2_parse_contexts().\n\nThis fixes following oops when accessing invalid create contexts from\nserver:\n\n  BUG: unable to handle page fault for address: ffff8881178d8cc3\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 4a01067 P4D 4a01067 PUD 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\n  rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n  RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]\n  Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00\n  00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 \u0026lt;0f\u0026gt; b7\n  7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00\n  RSP: 0018:ffffc900007939e0 EFLAGS: 00010216\n  RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90\n  RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000\n  RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000\n  R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000\n  R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22\n  FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)\n  knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0\n  PKRU: 55555554\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __die+0x23/0x70\n   ? page_fault_oops+0x181/0x480\n   ? search_module_extables+0x19/0x60\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? exc_page_fault+0x1b6/0x1c0\n   ? asm_exc_page_fault+0x26/0x30\n   ? smb2_parse_contexts+0xa0/0x3a0 [cifs]\n   SMB2_open+0x38d/0x5f0 [cifs]\n   ? smb2_is_path_accessible+0x138/0x260 [cifs]\n   smb2_is_path_accessible+0x138/0x260 [cifs]\n   cifs_is_path_remote+0x8d/0x230 [cifs]\n   cifs_mount+0x7e/0x350 [cifs]\n   cifs_smb3_do_mount+0x128/0x780 [cifs]\n   smb3_get_tree+0xd9/0x290 [cifs]\n   vfs_get_tree+0x2c/0x100\n   ? capable+0x37/0x70\n   path_mount+0x2d7/0xb80\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? _raw_spin_unlock_irqrestore+0x44/0x60\n   __x64_sys_mount+0x11a/0x150\n   do_syscall_64+0x47/0xf0\n   entry_SYSCALL_64_after_hwframe+0x6f/0x77\n  RIP: 0033:0x7f8737657b1e(CVE-2023-52434)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix race condition between session lookup and expire\n\n Thread A                        +  Thread B\n ksmbd_session_lookup            |  smb2_sess_setup\n   sess = xa_load                |\n                                 |\n                                 |    xa_erase(\u0026amp;conn-\u0026gt;sessions, sess-\u0026gt;id);\n                                 |\n                                 |    ksmbd_session_destroy(sess) --\u0026gt; kfree(sess)\n                                 |\n   // UAF!                       |\n   sess-\u0026gt;last_active = jiffies   |\n                                 +\n\nThis patch add rwsem to fix race condition between ksmbd_session_lookup\nand ksmbd_expire_session.(CVE-2023-52480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix buffer overflow in trans_stat_show\n\nFix buffer overflow in trans_stat_show().\n\nConvert simple snprintf to the more secure scnprintf with size of\nPAGE_SIZE.\n\nAdd condition checking if we are exceeding PAGE_SIZE and exit early from\nloop. Also add at the end a warning that we exceeded PAGE_SIZE and that\nstats is disabled.\n\nReturn -EFBIG in the case where we don\u0026apos;t have enough space to write the\nfull transition table.\n\nAlso document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7091r: Allow users to configure device events\n\nAD7091R-5 devices are supported by the ad7091r-5 driver together with\nthe ad7091r-base driver. Those drivers declared iio events for notifying\nuser space when ADC readings fall bellow the thresholds of low limit\nregisters or above the values set in high limit registers.\nHowever, to configure iio events and their thresholds, a set of callback\nfunctions must be implemented and those were not present until now.\nThe consequence of trying to configure ad7091r-5 events without the\nproper callback functions was a null pointer dereference in the kernel\nbecause the pointers to the callback functions were not set.\n\nImplement event configuration callbacks allowing users to read/write\nevent thresholds and enable/disable event generation.\n\nSince the event spec structs are generic to AD7091R devices, also move\nthose from the ad7091r-5 driver the base driver so they can be reused\nwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential context UAFs\n\ngem_context_register() makes the context visible to userspace, and which\npoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.\nSo we need to ensure that nothing uses the ctx ptr after this.  And we\nneed to ensure that adding the ctx to the xarray is the *last* thing\nthat gem_context_register() does with the ctx pointer.\n\n[tursulin: Stable and fixes tags add/tidy.]\n(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: handle isoc Babble and Buffer Overrun events properly\n\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\n\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n\u0026quot;Transfer event TRB DMA ptr not part of current TD\u0026quot; error message.\n\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\n\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Fix out-of-bounds memory access\n\nFix a bug that pdata-\u0026gt;cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.(CVE-2024-26664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations\n\n- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.\n- Disallow layer 4 protocol with no ports, since destination port is a\n  mandatory attribute for this object.(CVE-2024-26673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: roles: fix NULL pointer issue when put module\u0026apos;s reference\n\nIn current design, usb role class driver will get usb_role_switch parent\u0026apos;s\nmodule reference after the user get usb_role_switch device and put the\nreference after the user put the usb_role_switch device. However, the\nparent device of usb_role_switch may be removed before the user put the\nusb_role_switch. If so, then, NULL pointer issue will be met when the user\nput the parent module\u0026apos;s reference.\n\nThis will save the module pointer in structure of usb_role_switch. Then,\nwe don\u0026apos;t need to find module by iterating long relations.(CVE-2024-26747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829  if (request-\u0026gt;complete) {\n830          spin_unlock(\u0026amp;priv_dev-\u0026gt;lock);\n831          usb_gadget_giveback_request(\u0026amp;priv_ep-\u0026gt;endpoint,\n832                                    request);\n833          spin_lock(\u0026amp;priv_dev-\u0026gt;lock);\n834  }\n835\n836  if (request-\u0026gt;buf == priv_dev-\u0026gt;zlp_buf)\n837      cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][  T150]\n[ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0026apos;t call\nusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()\n\n  ...\n  cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, \u0026amp;priv_req-\u0026gt;request);\n  list_del_init(\u0026amp;priv_req-\u0026gt;list);\n  ...\n\n\u0026apos;priv_req\u0026apos; actually free at cdns3_gadget_ep_free_request(). But\nlist_del_init() use priv_req-\u0026gt;list after it.\n\n[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4\n[ 1542.642868][  T534]\n[ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):\n[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4\n[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]\n[ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4\n[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8\n[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368\n[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28\n\nMove list_del_init() before cdns3_gadget_ep_free_request() to resolve this\nproblem.(CVE-2024-26749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio/akcipher - Fix stack overflow on memcpy\n\nsizeof(struct virtio_crypto_akcipher_session_para) is less than\nsizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from\nstack variable leads stack overflow. Clang reports this issue by\ncommands:\nmake -j CC=clang-14 mrproper \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build CC=clang-14 allmodconfig \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/\n  virtio_crypto_akcipher_algs.o(CVE-2024-26753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix possible deadlock in subflow diag\n\nSyzbot and Eric reported a lockdep splat in the subflow diag:\n\n   WARNING: possible circular locking dependency detected\n   6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted\n\n   syz-executor.2/24141 is trying to acquire lock:\n   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n\n   but task is already holding lock:\n   ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock\n   include/linux/spinlock.h:351 [inline]\n   ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at:\n   inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038\n\n   which lock already depends on the new lock.\n\n   the existing dependency chain (in reverse order) is:\n\n   -\u0026gt; #1 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}:\n   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n   _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154\n   spin_lock include/linux/spinlock.h:351 [inline]\n   __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743\n   inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261\n   __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217\n   inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239\n   rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316\n   rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577\n   ops_init+0x352/0x610 net/core/net_namespace.c:136\n   __register_pernet_operations net/core/net_namespace.c:1214 [inline]\n   register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283\n   register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370\n   rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735\n   do_one_initcall+0x238/0x830 init/main.c:1236\n   do_initcall_level+0x157/0x210 init/main.c:1298\n   do_initcalls+0x3f/0x80 init/main.c:1314\n   kernel_init_freeable+0x42f/0x5d0 init/main.c:1551\n   kernel_init+0x1d/0x2a0 init/main.c:1441\n   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n   ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n\n   -\u0026gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:\n   check_prev_add kernel/locking/lockdep.c:3134 [inline]\n   check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n   validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n   __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n   lock_sock_fast include/net/sock.h:1723 [inline]\n   subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28\n   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n   inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345\n   inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061\n   __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263\n   inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371\n   netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264\n   __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370\n   netlink_dump_start include/linux/netlink.h:338 [inline]\n   inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405\n   sock_diag_rcv_msg+0xe7/0x410\n   netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n   sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n   netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n   netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n   netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n   sock_sendmsg_nosec net/socket.c:730 [inline]\n   __sock_sendmsg+0x221/0x270 net/socket.c:745\n   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n   ___sys_sendmsg net/socket.c:2638 [inline]\n   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n   do_syscall_64+0xf9/0x240\n   entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nAs noted by Eric we can break the lock dependency chain avoid\ndumping \n---truncated---(CVE-2024-26781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.(CVE-2024-26790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS:  00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985]  ? __die_body.cold+0x1a/0x1f\n[ 1010.715995]  ? die_addr+0x43/0x70\n[ 1010.716002]  ? exc_general_protection+0x199/0x2f0\n[ 1010.716016]  ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026]  ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034]  ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042]  __rtnl_newlink+0x1063/0x1700\n[ 1010.716051]  ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063]  ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070]  ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076]  ? __kernel_text_address+0x56/0xa0\n[ 1010.716084]  ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091]  ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098]  ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106]  ? stack_trace_save+0x91/0xd0\n[ 1010.716113]  ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121]  ? __lock_acquire+0x15c5/0x5380\n[ 1010.716139]  ? mark_held_locks+0x9e/0xe0\n[ 1010.716148]  ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155]  ? __rtnl_newlink+0x1700/0x1700\n[ 1010.716160]  rtnl_newlink+0x69/0xa0\n[ 1010.716166]  rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172]  ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179]  ? lock_acquire+0x1fe/0x560\n[ 1010.716188]  ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196]  netlink_rcv_skb+0x14d/0x440\n[ 1010.716202]  ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208]  ? netlink_ack+0xab0/0xab0\n[ 1010.716213]  ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220]  ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226]  ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233]  netlink_unicast+0x54b/0x800\n[ 1010.716240]  ? netlink_attachskb+0x870/0x870\n[ 1010.716248]  ? __check_object_size+0x2de/0x3b0\n[ 1010.716254]  netlink_sendmsg+0x938/0xe40\n[ 1010.716261]  ? netlink_unicast+0x800/0x800\n[ 1010.716269]  ? __import_iovec+0x292/0x510\n[ 1010.716276]  ? netlink_unicast+0x800/0x800\n[ 1010.716284]  __sock_sendmsg+0x159/0x190\n[ 1010.716290]  ____sys_sendmsg+0x712/0x880\n[ 1010.716297]  ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304]  ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309]  ? lock_acquire+0x1fe/0x560\n[ 1010.716315]  ? drain_array_locked+0x90/0x90\n[ 1010.716324]  ___sys_sendmsg+0xf8/0x170\n[ 1010.716331]  ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337]  ? lockdep_init_map\n---truncated---(CVE-2024-26793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\n\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  rpm_resume+0xe0/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  clk_pm_runtime_get+0x30/0xb0\n  clk_disable_unused_subtree+0x58/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused_subtree+0x38/0x208\n  clk_disable_unused+0x4c/0xe4\n  do_one_initcall+0xcc/0x2d8\n  do_initcall_level+0xa4/0x148\n  do_initcalls+0x5c/0x9c\n  do_basic_setup+0x24/0x30\n  kernel_init_freeable+0xec/0x164\n  kernel_init+0x28/0x120\n  ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n       Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n  __switch_to+0xf4/0x1f4\n  __schedule+0x418/0xb80\n  schedule+0x5c/0x10c\n  schedule_preempt_disabled+0x2c/0x48\n  __mutex_lock+0x238/0x488\n  __mutex_lock_slowpath+0x1c/0x28\n  mutex_lock+0x50/0x74\n  clk_prepare_lock+0x7c/0x9c\n  clk_core_prepare_lock+0x20/0x44\n  clk_prepare+0x24/0x30\n  clk_bulk_prepare+0x40/0xb0\n  mdss_runtime_resume+0x54/0x1c8\n  pm_generic_runtime_resume+0x30/0x44\n  __genpd_runtime_resume+0x68/0x7c\n  genpd_runtime_resume+0x108/0x1f4\n  __rpm_callback+0x84/0x144\n  rpm_callback+0x30/0x88\n  rpm_resume+0x1f4/0x52c\n  rpm_resume+0x178/0x52c\n  __pm_runtime_resume+0x58/0x98\n  __device_attach+0xe0/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  device_add+0x644/0x814\n  mipi_dsi_device_register_full+0xe4/0x170\n  devm_mipi_dsi_device_register_full+0x28/0x70\n  ti_sn_bridge_probe+0x1dc/0x2c0\n  auxiliary_bus_probe+0x4c/0x94\n  really_probe+0xcc/0x2c8\n  __driver_probe_device+0xa8/0x130\n  driver_probe_device+0x48/0x110\n  __device_attach_driver+0xa4/0xcc\n  bus_for_each_drv+0x8c/0xd8\n  __device_attach+0xf8/0x170\n  device_initial_probe+0x1c/0x28\n  bus_probe_device+0x3c/0x9c\n  deferred_probe_work_func+0x9c/0xd8\n  process_one_work+0x148/0x518\n  worker_thread+0x138/0x350\n  kthread+0x138/0x1e0\n  ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0026apos;ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0026apos;re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0026apos;t have the chance to\nschedule away with the prepare_lock held. Let\u0026apos;s fix this immediate\nproblem that can be\n---truncated---(CVE-2024-27004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn\u0026apos;t\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel\u0026apos;s native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n  safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n  instruction out-of-line when that instruction cannot be stepped\n  out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n  interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn\u0026apos;t caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n  the compiler and sparse have no idea these contain a little-endian\n  32-bit value. The core uprobes code populates these with a memcpy()\n  which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n  to the similarly-named probe_opcode_t, which is an alias for u32.\n  Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include \u0026lt;stdio.h\u0026gt;\n| #include \u0026lt;stdbool.h\u0026gt;\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n|         void *addr;\n|\n|         asm volatile(\n|         \u0026quot;       adrp    %x0, adrp_self\\n\u0026quot;\n|         \u0026quot;       add     %x0, %x0, :lo12:adrp_self\\n\u0026quot;\n|         : \u0026quot;=r\u0026quot; (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n|         void *ptr = adrp_self();\n|         bool equal = (ptr == adrp_self);\n|\n|         printf(\u0026quot;adrp_self   =\u0026gt; %p\\n\u0026quot;\n|                \u0026quot;adrp_self() =\u0026gt; %p\\n\u0026quot;\n|                \u0026quot;%s\\n\u0026quot;,\n|                adrp_self, ptr, equal ? \u0026quot;EQUAL\u0026quot; : \u0026quot;NOT EQUAL\u0026quot;);\n|\n|         return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 \u0026lt;adrp_self\u0026gt;:\n|   4007e0:       90000000        adrp    x0, 400000 \u0026lt;__ehdr_start\u0026gt;\n|   4007e4:       911f8000        add     x0, x0, #0x7e0\n|   4007e8:       d65f03c0        ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| #\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL(CVE-2024-50194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix flushing uninitialized delayed_work on cache_ctr error\n\nAn unexpected WARN_ON from flush_work() may occur when cache creation\nfails, caused by destroying the uninitialized delayed_work waker in the\nerror path of cache_create(). For example, the warning appears on the\nsuperblock checksum error.\n\nReproduce steps:\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\nWARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890\n\nFix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s\nerror path. This patch doesn\u0026apos;t affect the use-after-free fix for\nconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix\nUAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure.  In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: net: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the uml_net instance. Otherwise, removing a network device will\nresult in a crash:\n\nRIP: 0033:net_device_release+0x10/0x6f\nRSP: 00000000e20c7c40  EFLAGS: 00010206\nRAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0\nRDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028\nRBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70\nR10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000\nR13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 627af028 62c7af00 e20c7c80 60276fcd\n 62778000 603f5820 627af028 00000000\n e20c7cb0 603a2bcd 627af000 62770010\nCall Trace:\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;6002ec9c\u0026gt;] net_remove+0x63/0x69\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;60087d40\u0026gt;] ? __remove_hrtimer+0x38/0x74\n [\u0026lt;60087ff8\u0026gt;] ? hrtimer_try_to_cancel+0x8c/0x98\n [\u0026lt;6006b3cf\u0026gt;] ? dl_server_stop+0x3f/0x48\n [\u0026lt;6006b390\u0026gt;] ? dl_server_stop+0x0/0x48\n [\u0026lt;600672e8\u0026gt;] ? dequeue_entities+0x327/0x390\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[  356.775250] ------------[ cut here ]------------\n[  356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n    ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n    [...]\n    memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n           user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Require entities to have a non-zero unique ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nSo, deny allocating an entity with ID 0 or an ID that belongs to a unit\nthat is already added to the list of entities.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[   20.830206] usb 1-1: Using ep0 maxpacket: 8\n[   20.833501] usb 1-1: config 0 descriptor??\n[   21.038518] usb 1-1: string descriptor 0 read error: -71\n[   21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[   21.042218] ------------[ cut here ]------------\n[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[   21.043195] Modules linked in:\n[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[   21.044639] Workqueue: usb_hub_wq hub_event\n[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[   21.051136] PKRU: 55555554\n[   21.051331] Call Trace:\n[   21.051480]  \u0026lt;TASK\u0026gt;\n[   21.051611]  ? __warn+0xc4/0x210\n[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.052252]  ? report_bug+0x11b/0x1a0\n[   21.052540]  ? trace_hardirqs_on+0x31/0x40\n[   21.052901]  ? handle_bug+0x3d/0x70\n[   21.053197]  ? exc_invalid_op+0x1a/0x50\n[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20\n[   21.053924]  ? media_create_pad_link+0x91/0x2e0\n[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0\n[   21.054834]  ? media_create_pad_link+0x91/0x2e0\n[   21.055131]  ? _raw_spin_unlock+0x1e/0x40\n[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210\n[   21.055837]  uvc_mc_register_entities+0x358/0x400\n[   21.056144]  uvc_register_chains+0x1fd/0x290\n[   21.056413]  uvc_probe+0x380e/0x3dc0\n[   21.056676]  ? __lock_acquire+0x5aa/0x26e0\n[   21.056946]  ? find_held_lock+0x33/0xa0\n[   21.057196]  ? kernfs_activate+0x70/0x80\n[   21.057533]  ? usb_match_dy\n---truncated---(CVE-2024-56571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855]   ESR = 0x0000000096000004\n[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125]   SET = 0, FnV = 0\n[67840.878291]   EA = 0, S1PTW = 0\n[67840.881545]   FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456]  down_write+0x30/0x98\n[67841.096017]  start_creating.part.0+0x60/0x198\n[67841.100613]  debugfs_create_dir+0x48/0x1f8\n[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115]  full_proxy_write+0x68/0xc8\n[67841.129175]  vfs_write+0xd8/0x3f0\n[67841.132708]  ksys_write+0x70/0x108\n[67841.136317]  __arm64_sys_write+0x24/0x38\n[67841.140440]  invoke_syscall+0x50/0x128\n[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273]  do_el0_svc+0x24/0x38\n[67841.152773]  el0_svc+0x38/0xd8\n[67841.156009]  el0t_64_sync_handler+0xc0/0xc8\n[67841.160361]  el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last  enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last  enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n|  \u0026lt;IRQ\u0026gt;\n|  dump_stack_lvl+0x7e/0xc0\n|  dump_stack+0x1d/0x30\n|  __might_resched+0x1a2/0x270\n|  rt_spin_lock+0x68/0x170\n|  kcsan_skip_report_debugfs+0x43/0xe0\n|  print_report+0xb5/0x590\n|  kcsan_report_known_origin+0x1b1/0x1d0\n|  kcsan_setup_watchpoint+0x348/0x650\n|  __tsan_unaligned_write1+0x16d/0x1d0\n|  hrtimer_interrupt+0x3d6/0x430\n|  __sysvec_apic_timer_interrupt+0xe8/0x3a0\n|  sysvec_apic_timer_interrupt+0x97/0xc0\n|  \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM\n\nWe currently assume that there is at least one VMA in a MM, which isn\u0026apos;t\ntrue.\n\nSo we might end up having find_vma() return NULL, to then de-reference\nNULL.  So properly handle find_vma() returning NULL.\n\nThis fixes the report:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nRIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]\nRIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194\nCode: ...\nRSP: 0018:ffffc9000375fd08 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000\nRDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044\nRBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1\nR10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003\nR13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8\nFS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709\n __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]\n __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]\n __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022]  ? __dentry_kill+0x121/0x170\n[596663.813030]  ? _cond_resched+0x15/0x30\n[596663.813034]  ? _cond_resched+0x15/0x30\n[596663.813039]  ? wait_for_completion+0x35/0x190\n[596663.813048]  ? try_to_wake_up+0x63/0x540\n[596663.813055]  free_task+0x5a/0x60\n[596663.813061]  kthread_stop+0xf3/0x100\n[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota.  Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed.  Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)",
  "id": "OESA-2025-1096",
  "modified": "2026-08-06T11:08:11Z",
  "published": "2025-02-08T11:08:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52434"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52480"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52627"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26790"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26793"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26952"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50280"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53131"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56571"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56610"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56611"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56715"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2023-52434",
    "CVE-2023-52480",
    "CVE-2023-52614",
    "CVE-2023-52627",
    "CVE-2023-52913",
    "CVE-2024-24857",
    "CVE-2024-24859",
    "CVE-2024-26659",
    "CVE-2024-26664",
    "CVE-2024-26673",
    "CVE-2024-26747",
    "CVE-2024-26748",
    "CVE-2024-26749",
    "CVE-2024-26753",
    "CVE-2024-26781",
    "CVE-2024-26790",
    "CVE-2024-26793",
    "CVE-2024-26952",
    "CVE-2024-26954",
    "CVE-2024-27004",
    "CVE-2024-36479",
    "CVE-2024-37021",
    "CVE-2024-40965",
    "CVE-2024-50194",
    "CVE-2024-50280",
    "CVE-2024-53131",
    "CVE-2024-53183",
    "CVE-2024-53198",
    "CVE-2024-53201",
    "CVE-2024-56539",
    "CVE-2024-56571",
    "CVE-2024-56588",
    "CVE-2024-56610",
    "CVE-2024-56611",
    "CVE-2024-56623",
    "CVE-2024-56688",
    "CVE-2024-56704",
    "CVE-2024-56715",
    "CVE-2024-56746",
    "CVE-2024-57892"
  ]
}