{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-235.0.0.134.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-235.0.0.134.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-235.0.0.134.oe2203sp4"
            }
          ],
          "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:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm \u0026quot;python3\u0026quot;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_add_data_with_key  gcdev_register() \u0026amp; gcdev_unregister() would call device_add() \u0026amp; device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.  However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().  Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.  Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().  While at it, fix another subtle issue, i.e. when gc-\u0026gt;ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It\u0026apos;s not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev-\u0026gt;descs variable.(CVE-2022-48975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  riscv: Sync efi page table\u0026apos;s kernel mappings before switching  The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic.  Fix that by updating the efi kernel mappings before switching to the efi page table.(CVE-2022-49004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg_write_event_control(): fix a user-triggerable oops\r\n\r\nwe are *not* guaranteed that anything past the terminating NUL\nis mapped (let alone initialized with anything sane).(CVE-2024-45021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix a potential NULL pointer dereference\r\n\r\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\r\n\r\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\r\n\r\n(I found this bug during code inspection.)(CVE-2024-46677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check BIOS images before it is used\r\n\r\nBIOS images may fail to load and null checks are added before they are\nused.\r\n\r\nThis fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfsnotify: clear PARENT_WATCHED flags lazily\r\n\r\nIn some setups directories can have many (usually negative) dentries.\nHence __fsnotify_update_child_dentry_flags() function can take a\nsignificant amount of time. Since the bulk of this function happens\nunder inode-\u0026gt;i_lock this causes a significant contention on the lock\nwhen we remove the watch from the directory as the\n__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()\nraces with __fsnotify_update_child_dentry_flags() calls from\n__fsnotify_parent() happening on children. This can lead upto softlockup\nreports reported by users.\r\n\r\nFix the problem by calling fsnotify_update_children_dentry_flags() to\nset PARENT_WATCHED flags only when parent starts watching children.\r\n\r\nWhen parent stops watching children, clear false positive PARENT_WATCHED\nflags lazily in __fsnotify_parent() for each accessed child.(CVE-2024-47660)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\r\n\r\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we\u0026apos;ll\nstill have a preallocated node that might be used later.\r\n\r\nIf we then use that node for a new non-root node, it\u0026apos;ll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.(CVE-2024-47668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: pause TCM when the firmware is stopped\r\n\r\nNot doing so will make us send a host command to the transport while the\nfirmware is not alive, which will trigger a WARNING.\r\n\r\nbad state = 0\nWARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nRIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]\n iwl_mvm_config_scan+0x198/0x260 [iwlmvm]\n iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]\n iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]\n process_one_work+0x29e/0x640\n worker_thread+0x2df/0x690\n ? rescuer_thread+0x540/0x540\n kthread+0x192/0x1e0\n ? set_kthread_struct+0x90/0x90\n ret_from_fork+0x22/0x30(CVE-2024-47673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: get rid of online repaire on corrupted directory  syzbot reports a f2fs bug as below:  kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace:  evict+0x532/0x950 fs/inode.c:704  dispose_list fs/inode.c:747 [inline]  evict_inodes+0x5f9/0x690 fs/inode.c:797  generic_shutdown_super+0x9d/0x2d0 fs/super.c:627  kill_block_super+0x44/0x90 fs/super.c:1696  kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898  deactivate_locked_super+0xc4/0x130 fs/super.c:473  cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373  task_work_run+0x24f/0x310 kernel/task_work.c:228  ptrace_notify+0x2d2/0x380 kernel/signal.c:2402  ptrace_report_syscall include/linux/ptrace.h:415 [inline]  ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]  syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173  syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]  __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]  syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218  do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896  Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic.  Let\u0026apos;s get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The root cause is below race condition, it may cause use-after-free issue in sbi-\u0026gt;gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th)     - f2fs_ioc_shutdown      - f2fs_do_shutdown       - f2fs_stop_gc_thread        - kthread_stop(gc_th-\u0026gt;f2fs_gc_task)    : sbi-\u0026gt;gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb-\u0026gt;s_umount semaphore for fixing. - for f2fs_shutdown() path, it\u0026apos;s safe since caller has already grabbed sb-\u0026gt;s_umount semaphore.(CVE-2024-47691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u0026lt;0f\u0026gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\u0026quot;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn\u0026apos;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn\u0026apos;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  \u0026lt;TASK\u0026gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  \u0026lt;/TASK\u0026gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()  Patch series \u0026quot;nilfs2: fix potential issues with empty b-tree nodes\u0026quot;.  This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot.   This patch (of 3):  If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().  This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called.  Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency.  Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  \u0026lt;/TASK\u0026gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  block: fix potential invalid pointer dereference in blk_add_partition  The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer.  This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.(CVE-2024-47705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix out-of-bounds in dbNextAG() and diAlloc()  In dbNextAG() , there is no check for the case where bmp-\u0026gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount().  And in dbNextAG(), a check for the case where agpref is greater than bmp-\u0026gt;db_numag should be added, so an out-of-bounds exception should be prevented.  Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to wait dio completion  It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  padata: use integer wrap around to prevent deadlock on seq_nr overflow  When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata-\u0026gt;seq_nr and pd-\u0026gt;processed because the padata instance with overflowed seq_nr will be selected next.  To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from \u0026quot;ModelName\u0026quot;, a string that was previously parsed out of    some descriptor (\u0026quot;Vital Product Data\u0026quot;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-\u0026gt;hwinfo, \u0026quot;nffw.partno\u0026quot;), which I    think parses some descriptor that was read from the device.    (But this case likely isn\u0026apos;t exploitable because the format string looks    like \u0026quot;netronome/nic_%s\u0026quot;, and there shouldn\u0026apos;t be any *folders* starting    with \u0026quot;netronome/nic_\u0026quot;. The previous case was different because there,    the \u0026quot;%s\u0026quot; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing \u0026quot;..\u0026quot; path components.  For what it\u0026apos;s worth, I went looking and haven\u0026apos;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vhost_vdpa: assign irq bypass producer token correctly  We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don\u0026apos;t know if the token pointer is still valid or not.  Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status().  Fixing this by setting up irq bypass producer\u0026apos;s token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: keystone: Fix if-statement expression in ks_pcie_quirk()  This code accidentally uses \u0026amp;\u0026amp; where || was intended.  It potentially results in a NULL dereference.  Thus, fix the if-statement expression to use the correct condition.  [kwilczynski: commit log](CVE-2024-47756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nbd: fix race between timeout and normal completion  If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.  Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-\u0026gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption  The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table.  The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved.  Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let\u0026apos;s use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to check atomic_file in f2fs ioctl interfaces  Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  powercap: intel_rapl: Fix off by one in get_rpi()  The rp-\u0026gt;priv-\u0026gt;rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements.  Thus the \u0026gt; needs to be \u0026gt;= to prevent an off by one access.(CVE-2024-49862)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm: omapdrm: Add missing check for alloc_ordered_workqueue  As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.(CVE-2024-49879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don\u0026apos;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth \u0026gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-\u0026gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-\u0026gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-\u0026gt;p_depth = 0        |    brelse(path[1].p_bh)  ---\u0026gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-\u0026gt;p_depth = 1              read_extent_tree_block  ---\u0026gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-\u0026gt;p_depth == 1                  brelse(path[1].p_bh)  ---\u0026gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  \u0026lt;TASK\u0026gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we\u0026apos;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth \u0026gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  \u0026lt;TASK\u0026gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-\u0026gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug  Attaching SST PCI device to VM causes \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot;. kasan report: [   19.411889] ================================================================== [   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [   19.417368] [   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10 [   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [   19.422687] Call Trace: [   19.424091]  \u0026lt;TASK\u0026gt; [   19.425448]  dump_stack_lvl+0x5d/0x80 [   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.428694]  print_report+0x19d/0x52e [   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.433539]  kasan_report+0xf0/0x170 [   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10 [   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common] [   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360 [   19.444797]  cpuhp_invoke_callback+0x221/0xec0 [   19.446337]  cpuhp_thread_fun+0x21b/0x610 [   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10 [   19.449354]  smpboot_thread_fn+0x2e7/0x6e0 [   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10 [   19.452405]  kthread+0x29c/0x350 [   19.453817]  ? __pfx_kthread+0x10/0x10 [   19.455253]  ret_from_fork+0x31/0x70 [   19.456685]  ? __pfx_kthread+0x10/0x10 [   19.458114]  ret_from_fork_asm+0x1a/0x30 [   19.459573]  \u0026lt;/TASK\u0026gt; [   19.460853] [   19.462055] Allocated by task 1198: [   19.463410]  kasan_save_stack+0x30/0x50 [   19.464788]  kasan_save_track+0x14/0x30 [   19.466139]  __kasan_kmalloc+0xaa/0xb0 [   19.467465]  __kmalloc+0x1cd/0x470 [   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common] [   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [   19.471670]  do_one_initcall+0xa4/0x380 [   19.472903]  do_init_module+0x238/0x760 [   19.474105]  load_module+0x5239/0x6f00 [   19.475285]  init_module_from_file+0xd1/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.478920]  do_syscall_64+0x82/0x160 [   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   19.481292] [   19.482205] The buggy address belongs to the object at ffff888829e65000  which belongs to the cache kmalloc-512 of size 512 [   19.484818] The buggy address is located 0 bytes to the right of  allocated 512-byte region [ffff888829e65000, ffff888829e65200) [   19.487447] [   19.488328] The buggy address belongs to the physical page: [   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [   19.493914] page_type: 0xffffffff() [   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [   19.503784] page dumped because: k ---truncated---(CVE-2024-49886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since \u0026apos;path\u0026apos; is only used in ext4_ext_show_leaf(), remove \u0026apos;path\u0026apos; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream before comparing them  [WHAT \u0026amp; HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream  This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null.  The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed \u0026apos;top_pipe_to_program\u0026apos; could be null (see line 3906)(CVE-2024-49913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr and clk_mgr-\u0026gt;funcs in dcn30_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc-\u0026gt;clk_mgr` or `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is null.  The fix adds a check to ensure `dc-\u0026gt;clk_mgr` and `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed \u0026apos;dc-\u0026gt;clk_mgr\u0026apos; could be null (see line 628)(CVE-2024-49917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using them  [WHAT \u0026amp; HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again.  This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which \u0026amp;fbi-\u0026gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the \u0026amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-\u0026gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-\u0026gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-\u0026gt;lcd_power(on, \u0026amp;fbi-\u0026gt;fb.var)                                    | //use fbi-\u0026gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk_iocost: fix more out of bound shifts  Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function:  UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ...  Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name  It\u0026apos;s observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following:  ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x8d/0x190  ? do_user_addr_fault+0x2a0/0x790  ? report_bug+0x1c3/0x1d0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  ? do_user_addr_fault+0x2a0/0x790  ? exc_page_fault+0x31/0x200  exc_page_fault+0x68/0x200 \u0026lt;...snip...\u0026gt; BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  ---[ end trace 0000000000000000 ]---  BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014  RIP: 0010:dentry_name+0x1f4/0x440 \u0026lt;...snip...\u0026gt; ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130  Previously, some sanity check have been done in dump_mapping() before the print facility parsing \u0026apos;%pd\u0026apos; though, it\u0026apos;s still possible to run into an invalid dentry.d_name.name.  Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash.  Note that either retrieving the filename with \u0026apos;%pd\u0026apos; or strncpy_from_kernel_nofault(), the filename could be unreliable.(CVE-2024-49934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-\u0026gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  l2tp: prevent possible tunnel refcount underflow  When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session-\u0026gt;tunnel is non-NULL. However, session-\u0026gt;tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session-\u0026gt;tunnel is non-NULL when the tunnel refcount hasn\u0026apos;t been bumped.  Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session-\u0026gt;tunnel to get the tunnel\u0026apos;s encap. Add an encap arg to l2tp_session_set_header_len to avoid using session-\u0026gt;tunnel.  If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn\u0026apos;t yet have session-\u0026gt;tunnel set. Add a check for this case.(CVE-2024-49940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:488  kasan_report+0xd9/0x110 mm/kasan/report.c:601  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Replace pointless WARN_ON() in static_call_module_notify()  static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module().  That\u0026apos;s not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application.  A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set.  Replace it with a pr_warn().(CVE-2024-49954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: battery: Fix possible crash when unregistering a battery hook  When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash.  Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().(CVE-2024-49955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: reserve space for inline xattr before attaching reflink tree  One of our customers reported a crash and a corrupted ocfs2 filesystem.  The crash was due to the detection of corruption.  Upon troubleshooting, the fsck -fn output showed the below corruption  [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227.  Clamp the next record value? n  The stat output from the debugfs.ocfs2 showed the following corruption where the \u0026quot;Next Free Rec:\u0026quot; had overshot the \u0026quot;Count:\u0026quot; in the root metadata block.          Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)         FS Generation: 904309833 (0x35e6ac49)         CRC32: 00000000   ECC: 0000         Type: Regular   Attr: 0x0   Flags: Valid         Dynamic Features: (0x16) HasXattr InlineXattr Refcounted         Extended Attributes Block: 0  Extended Attributes Inline Size: 256         User: 0 (root)   Group: 0 (root)   Size: 281320357888         Links: 1   Clusters: 141738         ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024         atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024         mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024         dtime: 0x0 -- Wed Dec 31 17:00:00 1969         Refcount Block: 2777346         Last Extblk: 2886943   Orphan Slot: 0         Sub Alloc Slot: 0   Sub Alloc Bit: 14         Tree Depth: 1   Count: 227   Next Free Rec: 230         ## Offset        Clusters       Block#         0  0             2310           2776351         1  2310          2139           2777375         2  4449          1221           2778399         3  5670          731            2779423         4  6401          566            2780447         .......          ....           .......         .......          ....           .......  The issue was in the reflink workfow while reserving space for inline xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the time this function is called the reflink tree is already recreated at the destination inode from the source inode.  At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block.  It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption.  The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  r8169: add tally counter fields added with RTL8125  RTL8125 added fields to the tally counter, what may result in the chip dma\u0026apos;ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobes: fix kernel info leak via \u0026quot;[uprobes]\u0026quot; vma  xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn\u0026apos;t really matter, debugger can read this memory anyway.(CVE-2024-49975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gso: fix udp gso fraglist segmentation after pull from frag_list  Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly.  Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size  Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants.  In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg-\u0026gt;next)-\u0026gt;dest.  Detect invalid geometry due to pull, by checking head_skb size. Don\u0026apos;t just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-\u0026gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-\u0026gt;sys_err_done to make sync work. The core-\u0026gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/stm: Avoid use-after-free issues with crtc and plane  ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1].  Use allocations managed by the DRM framework.  Found by Linux Verification Center (linuxtesting.org).  [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() \u0026apos;media_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;media_name\u0026apos; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() \u0026apos;if_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;if_name\u0026apos; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (\u0026quot;[TIPC] Initial merge\u0026quot;)  Compile tested only.(CVE-2024-49995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cifs: Fix buffer overflow when parsing NFS reparse points  ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType\u0026apos;s size from ReparseDataLength.  Function cifs_strndup_from_utf16() is currentlly accessing buf-\u0026gt;DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.  Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.  Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().(CVE-2024-49996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Handle module init failure correctly in static_call_del_module()  Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.  If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.  This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.  The problem is that key::mods is not a individual struct member of struct static_call_key, it\u0026apos;s part of a union to save space:          union {                 /* bit 0: 0 = mods, 1 = sites */                 unsigned long type;                 struct static_call_mod *mods;                 struct static_call_site *sites;  };  key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.  As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.  Cure it by checking whether the key has a sites or a mods pointer.  If it\u0026apos;s a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.  If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.  A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can\u0026apos;t match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.(CVE-2024-50002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: asihpi: Fix potential OOB array access  ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware.  We shouldn\u0026apos;t trust it blindly.  This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()  Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`.  With this, fix the following warning:  elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \u0026quot;ext_scan-\u0026gt;tlv_buffer\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex](CVE-2024-50008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: dax: fix overflowing extents beyond inode size when partially writing  The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as:  dd if=/dev/urandom of=file bs=4M count=1  dax_iomap_rw   iomap_iter // round 1    ext4_iomap_begin     ext4_iomap_alloc // allocate 0~2M extents(written flag)   dax_iomap_iter // copy 2M data   iomap_iter // round 2    iomap_iter_advance     iter-\u0026gt;pos += iter-\u0026gt;processed // iter-\u0026gt;pos = 2M    ext4_iomap_begin     ext4_iomap_alloc // allocate 2~4M extents(written flag)   dax_iomap_iter    fatal_signal_pending   done = iter-\u0026gt;pos - iocb-\u0026gt;ki_pos // done = 2M  ext4_handle_inode_extension   ext4_update_inode_size // inode size = 2M  fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?  Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid overflow assignment in link_dp_cts  sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t.  Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4.  This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  igb: Do not bring the device up after non-fatal error  Commit 004d25060c78 (\u0026quot;igb: Fix igb_down hung on surprise removal\u0026quot;) changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below.  [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000 [  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000 [  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [  T292] pcieport 0000:00:1c.5: AER: broadcast resume message [  T292] ------------[ cut here ]------------ [  T292] kernel BUG at net/core/dev.c:6539! [  T292] invalid opcode: 0000 [#1] PREEMPT SMP [  T292] RIP: 0010:napi_enable+0x37/0x40 [  T292] Call Trace: [  T292]  \u0026lt;TASK\u0026gt; [  T292]  ? die+0x33/0x90 [  T292]  ? do_trap+0xdc/0x110 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? do_error_trap+0x70/0xb0 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? exc_invalid_op+0x4e/0x70 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? asm_exc_invalid_op+0x16/0x20 [  T292]  ? napi_enable+0x37/0x40 [  T292]  igb_up+0x41/0x150 [  T292]  igb_io_resume+0x25/0x70 [  T292]  report_resume+0x54/0x70 [  T292]  ? report_frozen_detected+0x20/0x20 [  T292]  pci_walk_bus+0x6c/0x90 [  T292]  ? aer_print_port_info+0xa0/0xa0 [  T292]  pcie_do_recovery+0x22f/0x380 [  T292]  aer_process_err_devices+0x110/0x160 [  T292]  aer_isr+0x1c1/0x1e0 [  T292]  ? disable_irq_nosync+0x10/0x10 [  T292]  irq_thread_fn+0x1a/0x60 [  T292]  irq_thread+0xe3/0x1a0 [  T292]  ? irq_set_affinity_notifier+0x120/0x120 [  T292]  ? irq_affinity_notify+0x100/0x100 [  T292]  kthread+0xe2/0x110 [  T292]  ? kthread_complete_and_exit+0x20/0x20 [  T292]  ret_from_fork+0x2d/0x50 [  T292]  ? kthread_complete_and_exit+0x20/0x20 [  T292]  ret_from_fork_asm+0x11/0x20 [  T292]  \u0026lt;/TASK\u0026gt;  To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.(CVE-2024-50040)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF in async decryption  Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API.  Reproducer:     # mount.cifs -o ...,seal,esize=1 //srv/share /mnt     # dd if=/mnt/largefile of=/dev/null     ...     [  194.196391] ==================================================================     [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110     [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899     [  194.197707]     [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43     [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014     [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]     [  194.200032] Call Trace:     [  194.200191]  \u0026lt;TASK\u0026gt;     [  194.200327]  dump_stack_lvl+0x4e/0x70     [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110     [  194.200809]  print_report+0x174/0x505     [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10     [  194.201352]  ? srso_return_thunk+0x5/0x5f     [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0     [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202128]  kasan_report+0xc8/0x150     [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202616]  gf128mul_4k_lle+0xc1/0x110     [  194.202863]  ghash_update+0x184/0x210     [  194.203103]  shash_ahash_update+0x184/0x2a0     [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10     [  194.203651]  ? srso_return_thunk+0x5/0x5f     [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340     [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140     [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]     [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]     [  194.208507]  ? srso_return_thunk+0x5/0x5f     [  194.209205]  ? srso_return_thunk+0x5/0x5f     [  194.209925]  ? srso_return_thunk+0x5/0x5f     [  194.210443]  ? srso_return_thunk+0x5/0x5f     [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]     [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]     [  194.214670]  ? srso_return_thunk+0x5/0x5f     [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]  This is because TFM is being used in parallel.  Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()).  Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it\u0026apos;s always going to be a synchronous operation.(CVE-2024-50047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \u0026quot;uart_port_dtr_rts(uport, false);\u0026quot; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition  In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then \u0026amp;sndev-\u0026gt;check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work.  If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                 CPU1                          | check_link_status_work switchtec_ntb_remove    | kfree(sndev);           |                         | if (sndev-\u0026gt;link_force_down)                         | // use sndev  Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.(CVE-2024-50059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring: check if we need to reschedule during overflow flush  In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it\u0026apos;ll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.  Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There\u0026apos;s no state to maintain here as overflows always prune from head-of-list, hence it\u0026apos;s fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tail call between progs attached to different hooks  bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed.  For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2\u0026apos;s prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed.  Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2\u0026apos;s return value 1 will be used as the return value for prog1\u0026apos;s hook file_alloc_security. That is, the return value rule is bypassed.  This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  zram: free secondary algorithms names  We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory.  [senozhatsky@chromium.org: kfree(NULL) is legal]   Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org(CVE-2024-50064)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won\u0026apos;t check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include \u0026lt;stdio.h\u0026gt; \\#include \u0026lt;stdlib.h\u0026gt; \\#include \u0026lt;string.h\u0026gt;  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i \u0026lt; n; ++i)     {         char c = i % 26 + \u0026apos;a\u0026apos;;         str[i] = c;     }     str[n-1] = \u0026apos;\\0\u0026apos;; }  void print_string(char *str) {     printf(\u0026quot;%s\\n\u0026quot;, str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \u0026quot;p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\u0026quot;  \u0026gt; uprobe_events echo 1 \u0026gt; events/uprobes/enable echo 1 \u0026gt; tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  \u0026lt;/TASK\u0026gt;  This commit enforces the buffer\u0026apos;s maxlen less than a page-size to avoid store_trace_args() out-of-memory access.(CVE-2024-50067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  parport: Proper fix for array out-of-bounds access  The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf().  However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.  Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: fix mptcp DSS corruption due to large pmtu xmit  Syzkaller was able to trigger a DSS corruption:    TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Modules linked in:   CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024   RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 \u0026lt;0f\u0026gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff   RSP: 0018:ffffc90000006db8 EFLAGS: 00010246   RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00   RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0   RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8   R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000   R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5   FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   Call Trace:    \u0026lt;IRQ\u0026gt;    move_skbs_to_msk net/mptcp/protocol.c:811 [inline]    mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854    subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490    tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283    tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350    ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205    ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    __netif_receive_skb_one_core net/core/dev.c:5662 [inline]    __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775    process_backlog+0x662/0x15b0 net/core/dev.c:6107    __napi_poll+0xcb/0x490 net/core/dev.c:6771    napi_poll net/core/dev.c:6840 [inline]    net_rx_action+0x89b/0x1240 net/core/dev.c:6962    handle_softirqs+0x2c5/0x980 kernel/softirq.c:554    do_softirq+0x11b/0x1e0 kernel/softirq.c:455    \u0026lt;/IRQ\u0026gt;    \u0026lt;TASK\u0026gt;    __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382    local_bh_enable include/linux/bottom_half.h:33 [inline]    rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]    __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451    dev_queue_xmit include/linux/netdevice.h:3094 [inline]    neigh_hh_output include/net/neighbour.h:526 [inline]    neigh_output include/net/neighbour.h:540 [inline]    ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236    ip_local_out net/ipv4/ip_output.c:130 [inline]    __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536    __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466    tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]    tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]    tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752    __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015    tcp_push_pending_frames include/net/tcp.h:2107 [inline]    tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]    tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    sk_backlog_rcv include/net/sock.h:1113 [inline]    __release_sock+0x214/0x350 net/core/sock.c:3072    release_sock+0x61/0x1f0 net/core/sock.c:3626    mptcp_push_ ---truncated---(CVE-2024-50083)",
  "id": "OESA-2024-2368",
  "modified": "2026-08-06T11:07:50Z",
  "published": "2024-11-08T11:07:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2368"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49004"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47660"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47668"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47690"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47691"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47696"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47699"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47703"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47705"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49862"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49881"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49933"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49950"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49973"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49992"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49996"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50007"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50015"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50033"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50040"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50059"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50060"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50063"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50064"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50067"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50074"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50083"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48961",
    "CVE-2022-48975",
    "CVE-2022-49004",
    "CVE-2024-45021",
    "CVE-2024-46677",
    "CVE-2024-46809",
    "CVE-2024-47659",
    "CVE-2024-47660",
    "CVE-2024-47668",
    "CVE-2024-47673",
    "CVE-2024-47690",
    "CVE-2024-47691",
    "CVE-2024-47693",
    "CVE-2024-47696",
    "CVE-2024-47699",
    "CVE-2024-47701",
    "CVE-2024-47703",
    "CVE-2024-47705",
    "CVE-2024-47723",
    "CVE-2024-47726",
    "CVE-2024-47739",
    "CVE-2024-47742",
    "CVE-2024-47748",
    "CVE-2024-47756",
    "CVE-2024-49855",
    "CVE-2024-49858",
    "CVE-2024-49859",
    "CVE-2024-49860",
    "CVE-2024-49862",
    "CVE-2024-49877",
    "CVE-2024-49879",
    "CVE-2024-49881",
    "CVE-2024-49882",
    "CVE-2024-49883",
    "CVE-2024-49884",
    "CVE-2024-49886",
    "CVE-2024-49889",
    "CVE-2024-49896",
    "CVE-2024-49913",
    "CVE-2024-49917",
    "CVE-2024-49922",
    "CVE-2024-49924",
    "CVE-2024-49933",
    "CVE-2024-49934",
    "CVE-2024-49936",
    "CVE-2024-49940",
    "CVE-2024-49950",
    "CVE-2024-49954",
    "CVE-2024-49955",
    "CVE-2024-49958",
    "CVE-2024-49973",
    "CVE-2024-49975",
    "CVE-2024-49978",
    "CVE-2024-49981",
    "CVE-2024-49992",
    "CVE-2024-49995",
    "CVE-2024-49996",
    "CVE-2024-50002",
    "CVE-2024-50007",
    "CVE-2024-50008",
    "CVE-2024-50015",
    "CVE-2024-50016",
    "CVE-2024-50028",
    "CVE-2024-50033",
    "CVE-2024-50035",
    "CVE-2024-50040",
    "CVE-2024-50047",
    "CVE-2024-50058",
    "CVE-2024-50059",
    "CVE-2024-50060",
    "CVE-2024-50063",
    "CVE-2024-50064",
    "CVE-2024-50067",
    "CVE-2024-50074",
    "CVE-2024-50083"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-235.0.0.137.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-235.0.0.137.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-235.0.0.137.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-235.0.0.137.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-235.0.0.137.oe2203sp3"
            }
          ],
          "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:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm \u0026quot;python3\u0026quot;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_add_data_with_key  gcdev_register() \u0026amp; gcdev_unregister() would call device_add() \u0026amp; device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.  However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().  Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.  Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().  While at it, fix another subtle issue, i.e. when gc-\u0026gt;ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It\u0026apos;s not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev-\u0026gt;descs variable.(CVE-2022-48975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  riscv: Sync efi page table\u0026apos;s kernel mappings before switching  The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic.  Fix that by updating the efi kernel mappings before switching to the efi page table.(CVE-2022-49004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg_write_event_control(): fix a user-triggerable oops\r\n\r\nwe are *not* guaranteed that anything past the terminating NUL\nis mapped (let alone initialized with anything sane).(CVE-2024-45021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix a potential NULL pointer dereference\r\n\r\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\r\n\r\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\r\n\r\n(I found this bug during code inspection.)(CVE-2024-46677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check BIOS images before it is used\r\n\r\nBIOS images may fail to load and null checks are added before they are\nused.\r\n\r\nThis fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfsnotify: clear PARENT_WATCHED flags lazily\r\n\r\nIn some setups directories can have many (usually negative) dentries.\nHence __fsnotify_update_child_dentry_flags() function can take a\nsignificant amount of time. Since the bulk of this function happens\nunder inode-\u0026gt;i_lock this causes a significant contention on the lock\nwhen we remove the watch from the directory as the\n__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()\nraces with __fsnotify_update_child_dentry_flags() calls from\n__fsnotify_parent() happening on children. This can lead upto softlockup\nreports reported by users.\r\n\r\nFix the problem by calling fsnotify_update_children_dentry_flags() to\nset PARENT_WATCHED flags only when parent starts watching children.\r\n\r\nWhen parent stops watching children, clear false positive PARENT_WATCHED\nflags lazily in __fsnotify_parent() for each accessed child.(CVE-2024-47660)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\r\n\r\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we\u0026apos;ll\nstill have a preallocated node that might be used later.\r\n\r\nIf we then use that node for a new non-root node, it\u0026apos;ll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.(CVE-2024-47668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: pause TCM when the firmware is stopped\r\n\r\nNot doing so will make us send a host command to the transport while the\nfirmware is not alive, which will trigger a WARNING.\r\n\r\nbad state = 0\nWARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nRIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]\n iwl_mvm_config_scan+0x198/0x260 [iwlmvm]\n iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]\n iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]\n process_one_work+0x29e/0x640\n worker_thread+0x2df/0x690\n ? rescuer_thread+0x540/0x540\n kthread+0x192/0x1e0\n ? set_kthread_struct+0x90/0x90\n ret_from_fork+0x22/0x30(CVE-2024-47673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: get rid of online repaire on corrupted directory  syzbot reports a f2fs bug as below:  kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace:  evict+0x532/0x950 fs/inode.c:704  dispose_list fs/inode.c:747 [inline]  evict_inodes+0x5f9/0x690 fs/inode.c:797  generic_shutdown_super+0x9d/0x2d0 fs/super.c:627  kill_block_super+0x44/0x90 fs/super.c:1696  kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898  deactivate_locked_super+0xc4/0x130 fs/super.c:473  cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373  task_work_run+0x24f/0x310 kernel/task_work.c:228  ptrace_notify+0x2d2/0x380 kernel/signal.c:2402  ptrace_report_syscall include/linux/ptrace.h:415 [inline]  ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]  syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173  syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]  __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]  syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218  do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896  Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic.  Let\u0026apos;s get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The root cause is below race condition, it may cause use-after-free issue in sbi-\u0026gt;gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th)     - f2fs_ioc_shutdown      - f2fs_do_shutdown       - f2fs_stop_gc_thread        - kthread_stop(gc_th-\u0026gt;f2fs_gc_task)    : sbi-\u0026gt;gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb-\u0026gt;s_umount semaphore for fixing. - for f2fs_shutdown() path, it\u0026apos;s safe since caller has already grabbed sb-\u0026gt;s_umount semaphore.(CVE-2024-47691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u0026lt;0f\u0026gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\u0026quot;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn\u0026apos;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn\u0026apos;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  \u0026lt;TASK\u0026gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  \u0026lt;/TASK\u0026gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()  Patch series \u0026quot;nilfs2: fix potential issues with empty b-tree nodes\u0026quot;.  This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot.   This patch (of 3):  If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().  This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called.  Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency.  Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  \u0026lt;/TASK\u0026gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  block: fix potential invalid pointer dereference in blk_add_partition  The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer.  This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.(CVE-2024-47705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix out-of-bounds in dbNextAG() and diAlloc()  In dbNextAG() , there is no check for the case where bmp-\u0026gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount().  And in dbNextAG(), a check for the case where agpref is greater than bmp-\u0026gt;db_numag should be added, so an out-of-bounds exception should be prevented.  Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to wait dio completion  It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  padata: use integer wrap around to prevent deadlock on seq_nr overflow  When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata-\u0026gt;seq_nr and pd-\u0026gt;processed because the padata instance with overflowed seq_nr will be selected next.  To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from \u0026quot;ModelName\u0026quot;, a string that was previously parsed out of    some descriptor (\u0026quot;Vital Product Data\u0026quot;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-\u0026gt;hwinfo, \u0026quot;nffw.partno\u0026quot;), which I    think parses some descriptor that was read from the device.    (But this case likely isn\u0026apos;t exploitable because the format string looks    like \u0026quot;netronome/nic_%s\u0026quot;, and there shouldn\u0026apos;t be any *folders* starting    with \u0026quot;netronome/nic_\u0026quot;. The previous case was different because there,    the \u0026quot;%s\u0026quot; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing \u0026quot;..\u0026quot; path components.  For what it\u0026apos;s worth, I went looking and haven\u0026apos;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vhost_vdpa: assign irq bypass producer token correctly  We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don\u0026apos;t know if the token pointer is still valid or not.  Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status().  Fixing this by setting up irq bypass producer\u0026apos;s token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: keystone: Fix if-statement expression in ks_pcie_quirk()  This code accidentally uses \u0026amp;\u0026amp; where || was intended.  It potentially results in a NULL dereference.  Thus, fix the if-statement expression to use the correct condition.  [kwilczynski: commit log](CVE-2024-47756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nbd: fix race between timeout and normal completion  If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.  Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-\u0026gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption  The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table.  The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved.  Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let\u0026apos;s use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to check atomic_file in f2fs ioctl interfaces  Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  powercap: intel_rapl: Fix off by one in get_rpi()  The rp-\u0026gt;priv-\u0026gt;rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements.  Thus the \u0026gt; needs to be \u0026gt;= to prevent an off by one access.(CVE-2024-49862)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm: omapdrm: Add missing check for alloc_ordered_workqueue  As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.(CVE-2024-49879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don\u0026apos;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth \u0026gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-\u0026gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-\u0026gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-\u0026gt;p_depth = 0        |    brelse(path[1].p_bh)  ---\u0026gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-\u0026gt;p_depth = 1              read_extent_tree_block  ---\u0026gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-\u0026gt;p_depth == 1                  brelse(path[1].p_bh)  ---\u0026gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  \u0026lt;TASK\u0026gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we\u0026apos;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth \u0026gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  \u0026lt;TASK\u0026gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-\u0026gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug  Attaching SST PCI device to VM causes \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot;. kasan report: [   19.411889] ================================================================== [   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [   19.417368] [   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10 [   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [   19.422687] Call Trace: [   19.424091]  \u0026lt;TASK\u0026gt; [   19.425448]  dump_stack_lvl+0x5d/0x80 [   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.428694]  print_report+0x19d/0x52e [   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.433539]  kasan_report+0xf0/0x170 [   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10 [   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common] [   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360 [   19.444797]  cpuhp_invoke_callback+0x221/0xec0 [   19.446337]  cpuhp_thread_fun+0x21b/0x610 [   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10 [   19.449354]  smpboot_thread_fn+0x2e7/0x6e0 [   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10 [   19.452405]  kthread+0x29c/0x350 [   19.453817]  ? __pfx_kthread+0x10/0x10 [   19.455253]  ret_from_fork+0x31/0x70 [   19.456685]  ? __pfx_kthread+0x10/0x10 [   19.458114]  ret_from_fork_asm+0x1a/0x30 [   19.459573]  \u0026lt;/TASK\u0026gt; [   19.460853] [   19.462055] Allocated by task 1198: [   19.463410]  kasan_save_stack+0x30/0x50 [   19.464788]  kasan_save_track+0x14/0x30 [   19.466139]  __kasan_kmalloc+0xaa/0xb0 [   19.467465]  __kmalloc+0x1cd/0x470 [   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common] [   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [   19.471670]  do_one_initcall+0xa4/0x380 [   19.472903]  do_init_module+0x238/0x760 [   19.474105]  load_module+0x5239/0x6f00 [   19.475285]  init_module_from_file+0xd1/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.478920]  do_syscall_64+0x82/0x160 [   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   19.481292] [   19.482205] The buggy address belongs to the object at ffff888829e65000  which belongs to the cache kmalloc-512 of size 512 [   19.484818] The buggy address is located 0 bytes to the right of  allocated 512-byte region [ffff888829e65000, ffff888829e65200) [   19.487447] [   19.488328] The buggy address belongs to the physical page: [   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [   19.493914] page_type: 0xffffffff() [   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [   19.503784] page dumped because: k ---truncated---(CVE-2024-49886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since \u0026apos;path\u0026apos; is only used in ext4_ext_show_leaf(), remove \u0026apos;path\u0026apos; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream before comparing them  [WHAT \u0026amp; HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream  This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null.  The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed \u0026apos;top_pipe_to_program\u0026apos; could be null (see line 3906)(CVE-2024-49913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr and clk_mgr-\u0026gt;funcs in dcn30_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc-\u0026gt;clk_mgr` or `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is null.  The fix adds a check to ensure `dc-\u0026gt;clk_mgr` and `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed \u0026apos;dc-\u0026gt;clk_mgr\u0026apos; could be null (see line 628)(CVE-2024-49917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using them  [WHAT \u0026amp; HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again.  This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which \u0026amp;fbi-\u0026gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the \u0026amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-\u0026gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-\u0026gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-\u0026gt;lcd_power(on, \u0026amp;fbi-\u0026gt;fb.var)                                    | //use fbi-\u0026gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk_iocost: fix more out of bound shifts  Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function:  UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ...  Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name  It\u0026apos;s observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following:  ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x8d/0x190  ? do_user_addr_fault+0x2a0/0x790  ? report_bug+0x1c3/0x1d0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  ? do_user_addr_fault+0x2a0/0x790  ? exc_page_fault+0x31/0x200  exc_page_fault+0x68/0x200 \u0026lt;...snip...\u0026gt; BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  ---[ end trace 0000000000000000 ]---  BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014  RIP: 0010:dentry_name+0x1f4/0x440 \u0026lt;...snip...\u0026gt; ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130  Previously, some sanity check have been done in dump_mapping() before the print facility parsing \u0026apos;%pd\u0026apos; though, it\u0026apos;s still possible to run into an invalid dentry.d_name.name.  Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash.  Note that either retrieving the filename with \u0026apos;%pd\u0026apos; or strncpy_from_kernel_nofault(), the filename could be unreliable.(CVE-2024-49934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-\u0026gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  l2tp: prevent possible tunnel refcount underflow  When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session-\u0026gt;tunnel is non-NULL. However, session-\u0026gt;tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session-\u0026gt;tunnel is non-NULL when the tunnel refcount hasn\u0026apos;t been bumped.  Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session-\u0026gt;tunnel to get the tunnel\u0026apos;s encap. Add an encap arg to l2tp_session_set_header_len to avoid using session-\u0026gt;tunnel.  If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn\u0026apos;t yet have session-\u0026gt;tunnel set. Add a check for this case.(CVE-2024-49940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:488  kasan_report+0xd9/0x110 mm/kasan/report.c:601  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Replace pointless WARN_ON() in static_call_module_notify()  static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module().  That\u0026apos;s not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application.  A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set.  Replace it with a pr_warn().(CVE-2024-49954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: battery: Fix possible crash when unregistering a battery hook  When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash.  Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().(CVE-2024-49955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: reserve space for inline xattr before attaching reflink tree  One of our customers reported a crash and a corrupted ocfs2 filesystem.  The crash was due to the detection of corruption.  Upon troubleshooting, the fsck -fn output showed the below corruption  [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227.  Clamp the next record value? n  The stat output from the debugfs.ocfs2 showed the following corruption where the \u0026quot;Next Free Rec:\u0026quot; had overshot the \u0026quot;Count:\u0026quot; in the root metadata block.          Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)         FS Generation: 904309833 (0x35e6ac49)         CRC32: 00000000   ECC: 0000         Type: Regular   Attr: 0x0   Flags: Valid         Dynamic Features: (0x16) HasXattr InlineXattr Refcounted         Extended Attributes Block: 0  Extended Attributes Inline Size: 256         User: 0 (root)   Group: 0 (root)   Size: 281320357888         Links: 1   Clusters: 141738         ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024         atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024         mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024         dtime: 0x0 -- Wed Dec 31 17:00:00 1969         Refcount Block: 2777346         Last Extblk: 2886943   Orphan Slot: 0         Sub Alloc Slot: 0   Sub Alloc Bit: 14         Tree Depth: 1   Count: 227   Next Free Rec: 230         ## Offset        Clusters       Block#         0  0             2310           2776351         1  2310          2139           2777375         2  4449          1221           2778399         3  5670          731            2779423         4  6401          566            2780447         .......          ....           .......         .......          ....           .......  The issue was in the reflink workfow while reserving space for inline xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the time this function is called the reflink tree is already recreated at the destination inode from the source inode.  At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block.  It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption.  The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  r8169: add tally counter fields added with RTL8125  RTL8125 added fields to the tally counter, what may result in the chip dma\u0026apos;ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobes: fix kernel info leak via \u0026quot;[uprobes]\u0026quot; vma  xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn\u0026apos;t really matter, debugger can read this memory anyway.(CVE-2024-49975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gso: fix udp gso fraglist segmentation after pull from frag_list  Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly.  Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size  Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants.  In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg-\u0026gt;next)-\u0026gt;dest.  Detect invalid geometry due to pull, by checking head_skb size. Don\u0026apos;t just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-\u0026gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-\u0026gt;sys_err_done to make sync work. The core-\u0026gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/stm: Avoid use-after-free issues with crtc and plane  ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1].  Use allocations managed by the DRM framework.  Found by Linux Verification Center (linuxtesting.org).  [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() \u0026apos;media_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;media_name\u0026apos; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() \u0026apos;if_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;if_name\u0026apos; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (\u0026quot;[TIPC] Initial merge\u0026quot;)  Compile tested only.(CVE-2024-49995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cifs: Fix buffer overflow when parsing NFS reparse points  ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType\u0026apos;s size from ReparseDataLength.  Function cifs_strndup_from_utf16() is currentlly accessing buf-\u0026gt;DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.  Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.  Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().(CVE-2024-49996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Handle module init failure correctly in static_call_del_module()  Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.  If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.  This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.  The problem is that key::mods is not a individual struct member of struct static_call_key, it\u0026apos;s part of a union to save space:          union {                 /* bit 0: 0 = mods, 1 = sites */                 unsigned long type;                 struct static_call_mod *mods;                 struct static_call_site *sites;  };  key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.  As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.  Cure it by checking whether the key has a sites or a mods pointer.  If it\u0026apos;s a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.  If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.  A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can\u0026apos;t match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.(CVE-2024-50002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: asihpi: Fix potential OOB array access  ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware.  We shouldn\u0026apos;t trust it blindly.  This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()  Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`.  With this, fix the following warning:  elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \u0026quot;ext_scan-\u0026gt;tlv_buffer\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex](CVE-2024-50008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: dax: fix overflowing extents beyond inode size when partially writing  The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as:  dd if=/dev/urandom of=file bs=4M count=1  dax_iomap_rw   iomap_iter // round 1    ext4_iomap_begin     ext4_iomap_alloc // allocate 0~2M extents(written flag)   dax_iomap_iter // copy 2M data   iomap_iter // round 2    iomap_iter_advance     iter-\u0026gt;pos += iter-\u0026gt;processed // iter-\u0026gt;pos = 2M    ext4_iomap_begin     ext4_iomap_alloc // allocate 2~4M extents(written flag)   dax_iomap_iter    fatal_signal_pending   done = iter-\u0026gt;pos - iocb-\u0026gt;ki_pos // done = 2M  ext4_handle_inode_extension   ext4_update_inode_size // inode size = 2M  fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?  Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid overflow assignment in link_dp_cts  sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t.  Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4.  This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  igb: Do not bring the device up after non-fatal error  Commit 004d25060c78 (\u0026quot;igb: Fix igb_down hung on surprise removal\u0026quot;) changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below.  [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000 [  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000 [  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [  T292] pcieport 0000:00:1c.5: AER: broadcast resume message [  T292] ------------[ cut here ]------------ [  T292] kernel BUG at net/core/dev.c:6539! [  T292] invalid opcode: 0000 [#1] PREEMPT SMP [  T292] RIP: 0010:napi_enable+0x37/0x40 [  T292] Call Trace: [  T292]  \u0026lt;TASK\u0026gt; [  T292]  ? die+0x33/0x90 [  T292]  ? do_trap+0xdc/0x110 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? do_error_trap+0x70/0xb0 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? exc_invalid_op+0x4e/0x70 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? asm_exc_invalid_op+0x16/0x20 [  T292]  ? napi_enable+0x37/0x40 [  T292]  igb_up+0x41/0x150 [  T292]  igb_io_resume+0x25/0x70 [  T292]  report_resume+0x54/0x70 [  T292]  ? report_frozen_detected+0x20/0x20 [  T292]  pci_walk_bus+0x6c/0x90 [  T292]  ? aer_print_port_info+0xa0/0xa0 [  T292]  pcie_do_recovery+0x22f/0x380 [  T292]  aer_process_err_devices+0x110/0x160 [  T292]  aer_isr+0x1c1/0x1e0 [  T292]  ? disable_irq_nosync+0x10/0x10 [  T292]  irq_thread_fn+0x1a/0x60 [  T292]  irq_thread+0xe3/0x1a0 [  T292]  ? irq_set_affinity_notifier+0x120/0x120 [  T292]  ? irq_affinity_notify+0x100/0x100 [  T292]  kthread+0xe2/0x110 [  T292]  ? kthread_complete_and_exit+0x20/0x20 [  T292]  ret_from_fork+0x2d/0x50 [  T292]  ? kthread_complete_and_exit+0x20/0x20 [  T292]  ret_from_fork_asm+0x11/0x20 [  T292]  \u0026lt;/TASK\u0026gt;  To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.(CVE-2024-50040)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF in async decryption  Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API.  Reproducer:     # mount.cifs -o ...,seal,esize=1 //srv/share /mnt     # dd if=/mnt/largefile of=/dev/null     ...     [  194.196391] ==================================================================     [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110     [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899     [  194.197707]     [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43     [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014     [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]     [  194.200032] Call Trace:     [  194.200191]  \u0026lt;TASK\u0026gt;     [  194.200327]  dump_stack_lvl+0x4e/0x70     [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110     [  194.200809]  print_report+0x174/0x505     [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10     [  194.201352]  ? srso_return_thunk+0x5/0x5f     [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0     [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202128]  kasan_report+0xc8/0x150     [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202616]  gf128mul_4k_lle+0xc1/0x110     [  194.202863]  ghash_update+0x184/0x210     [  194.203103]  shash_ahash_update+0x184/0x2a0     [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10     [  194.203651]  ? srso_return_thunk+0x5/0x5f     [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340     [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140     [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]     [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]     [  194.208507]  ? srso_return_thunk+0x5/0x5f     [  194.209205]  ? srso_return_thunk+0x5/0x5f     [  194.209925]  ? srso_return_thunk+0x5/0x5f     [  194.210443]  ? srso_return_thunk+0x5/0x5f     [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]     [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]     [  194.214670]  ? srso_return_thunk+0x5/0x5f     [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]  This is because TFM is being used in parallel.  Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()).  Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it\u0026apos;s always going to be a synchronous operation.(CVE-2024-50047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \u0026quot;uart_port_dtr_rts(uport, false);\u0026quot; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition  In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then \u0026amp;sndev-\u0026gt;check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work.  If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                 CPU1                          | check_link_status_work switchtec_ntb_remove    | kfree(sndev);           |                         | if (sndev-\u0026gt;link_force_down)                         | // use sndev  Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.(CVE-2024-50059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring: check if we need to reschedule during overflow flush  In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it\u0026apos;ll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.  Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There\u0026apos;s no state to maintain here as overflows always prune from head-of-list, hence it\u0026apos;s fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tail call between progs attached to different hooks  bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed.  For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2\u0026apos;s prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed.  Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2\u0026apos;s return value 1 will be used as the return value for prog1\u0026apos;s hook file_alloc_security. That is, the return value rule is bypassed.  This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  zram: free secondary algorithms names  We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory.  [senozhatsky@chromium.org: kfree(NULL) is legal]   Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org(CVE-2024-50064)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won\u0026apos;t check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include \u0026lt;stdio.h\u0026gt; \\#include \u0026lt;stdlib.h\u0026gt; \\#include \u0026lt;string.h\u0026gt;  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i \u0026lt; n; ++i)     {         char c = i % 26 + \u0026apos;a\u0026apos;;         str[i] = c;     }     str[n-1] = \u0026apos;\\0\u0026apos;; }  void print_string(char *str) {     printf(\u0026quot;%s\\n\u0026quot;, str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \u0026quot;p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\u0026quot;  \u0026gt; uprobe_events echo 1 \u0026gt; events/uprobes/enable echo 1 \u0026gt; tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  \u0026lt;/TASK\u0026gt;  This commit enforces the buffer\u0026apos;s maxlen less than a page-size to avoid store_trace_args() out-of-memory access.(CVE-2024-50067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  parport: Proper fix for array out-of-bounds access  The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf().  However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.  Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: fix mptcp DSS corruption due to large pmtu xmit  Syzkaller was able to trigger a DSS corruption:    TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Modules linked in:   CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024   RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 \u0026lt;0f\u0026gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff   RSP: 0018:ffffc90000006db8 EFLAGS: 00010246   RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00   RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0   RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8   R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000   R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5   FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   Call Trace:    \u0026lt;IRQ\u0026gt;    move_skbs_to_msk net/mptcp/protocol.c:811 [inline]    mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854    subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490    tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283    tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350    ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205    ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    __netif_receive_skb_one_core net/core/dev.c:5662 [inline]    __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775    process_backlog+0x662/0x15b0 net/core/dev.c:6107    __napi_poll+0xcb/0x490 net/core/dev.c:6771    napi_poll net/core/dev.c:6840 [inline]    net_rx_action+0x89b/0x1240 net/core/dev.c:6962    handle_softirqs+0x2c5/0x980 kernel/softirq.c:554    do_softirq+0x11b/0x1e0 kernel/softirq.c:455    \u0026lt;/IRQ\u0026gt;    \u0026lt;TASK\u0026gt;    __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382    local_bh_enable include/linux/bottom_half.h:33 [inline]    rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]    __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451    dev_queue_xmit include/linux/netdevice.h:3094 [inline]    neigh_hh_output include/net/neighbour.h:526 [inline]    neigh_output include/net/neighbour.h:540 [inline]    ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236    ip_local_out net/ipv4/ip_output.c:130 [inline]    __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536    __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466    tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]    tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]    tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752    __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015    tcp_push_pending_frames include/net/tcp.h:2107 [inline]    tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]    tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    sk_backlog_rcv include/net/sock.h:1113 [inline]    __release_sock+0x214/0x350 net/core/sock.c:3072    release_sock+0x61/0x1f0 net/core/sock.c:3626    mptcp_push_ ---truncated---(CVE-2024-50083)",
  "id": "OESA-2024-2369",
  "modified": "2026-08-06T11:07:50Z",
  "published": "2024-11-08T11:07:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2369"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49004"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47660"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47668"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47690"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47691"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47696"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47699"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47703"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47705"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49862"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49881"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49933"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49950"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49973"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49992"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49996"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50007"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50015"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50033"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50040"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50059"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50060"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50063"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50064"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50067"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50074"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50083"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48961",
    "CVE-2022-48975",
    "CVE-2022-49004",
    "CVE-2024-45021",
    "CVE-2024-46677",
    "CVE-2024-46809",
    "CVE-2024-47659",
    "CVE-2024-47660",
    "CVE-2024-47668",
    "CVE-2024-47673",
    "CVE-2024-47690",
    "CVE-2024-47691",
    "CVE-2024-47693",
    "CVE-2024-47696",
    "CVE-2024-47699",
    "CVE-2024-47701",
    "CVE-2024-47703",
    "CVE-2024-47705",
    "CVE-2024-47723",
    "CVE-2024-47726",
    "CVE-2024-47739",
    "CVE-2024-47742",
    "CVE-2024-47748",
    "CVE-2024-47756",
    "CVE-2024-49855",
    "CVE-2024-49858",
    "CVE-2024-49859",
    "CVE-2024-49860",
    "CVE-2024-49862",
    "CVE-2024-49877",
    "CVE-2024-49879",
    "CVE-2024-49881",
    "CVE-2024-49882",
    "CVE-2024-49883",
    "CVE-2024-49884",
    "CVE-2024-49886",
    "CVE-2024-49889",
    "CVE-2024-49896",
    "CVE-2024-49913",
    "CVE-2024-49917",
    "CVE-2024-49922",
    "CVE-2024-49924",
    "CVE-2024-49933",
    "CVE-2024-49934",
    "CVE-2024-49936",
    "CVE-2024-49940",
    "CVE-2024-49950",
    "CVE-2024-49954",
    "CVE-2024-49955",
    "CVE-2024-49958",
    "CVE-2024-49973",
    "CVE-2024-49975",
    "CVE-2024-49978",
    "CVE-2024-49981",
    "CVE-2024-49992",
    "CVE-2024-49995",
    "CVE-2024-49996",
    "CVE-2024-50002",
    "CVE-2024-50007",
    "CVE-2024-50008",
    "CVE-2024-50015",
    "CVE-2024-50016",
    "CVE-2024-50028",
    "CVE-2024-50033",
    "CVE-2024-50035",
    "CVE-2024-50040",
    "CVE-2024-50047",
    "CVE-2024-50058",
    "CVE-2024-50059",
    "CVE-2024-50060",
    "CVE-2024-50063",
    "CVE-2024-50064",
    "CVE-2024-50067",
    "CVE-2024-50074",
    "CVE-2024-50083"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2411.2.0.0302.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2411.2.0.0302.oe2003sp4"
            }
          ],
          "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:  usb: gadget: uvc: Prevent buffer overflow in setup handler  Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req-\u0026gt;actual bytes to uvc_event-\u0026gt;data.data array of size 60. This may result in an overflow of 4 bytes.(CVE-2022-48948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  igb: Initialize mailbox message for VF reset  When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.(CVE-2022-48949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hix5hd2_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hisi_femac_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: mvneta: Prevent out of bounds read in mvneta_config_rss()  The pp-\u0026gt;indir[0] value comes from the user.  It is passed to:   if (cpu_online(pp-\u0026gt;rxq_def))  inside the mvneta_percpu_elect() function.  It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.(CVE-2022-48966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Fix not cleanup led when bt_init fails  bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it.  This can cause panic if the argument \u0026quot;bluetooth-power\u0026quot; in text is freed and then another led_trigger_register() tries to access it:  BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30   Call Trace:     \u0026lt;TASK\u0026gt;     led_trigger_register+0x10d/0x4f0     led_trigger_register_simple+0x7d/0x100     bt_init+0x39/0xf7 [bluetooth]     do_one_initcall+0xd0/0x4e0(CVE-2022-48971)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()  Kernel fault injection test reports null-ptr-deref as follows:  BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace:  \u0026lt;TASK\u0026gt;  raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87  call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944  unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982  unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879  register_netdevice+0x9a8/0xb90 net/core/dev.c:10083  ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659  ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229  mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316  ieee802154_if_add() allocates wpan_dev as netdev\u0026apos;s private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref.  Use INIT_LIST_HEAD() on it to initialize it correctly.(CVE-2022-48972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  HID: core: fix shift-out-of-bounds in hid_report_raw_event  Syzbot reported shift-out-of-bounds in hid_report_raw_event.  microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) \u0026gt; 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type \u0026apos;int\u0026apos; CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:  \u0026lt;IRQ\u0026gt;  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106  ubsan_epilogue lib/ubsan.c:151 [inline]  __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322  snto32 drivers/hid/hid-core.c:1323 [inline]  hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]  hid_process_report drivers/hid/hid-core.c:1665 [inline]  hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998  hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066  hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284  __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671  dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988  call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474  expire_timers kernel/time/timer.c:1519 [inline]  __run_timers+0x76a/0x980 kernel/time/timer.c:1790  run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803  __do_softirq+0x277/0x75b kernel/softirq.c:571  __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650  irq_exit_rcu+0x5/0x20 kernel/softirq.c:662  sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ======================================================================  If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type \u0026apos;int\u0026apos;, resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32.(CVE-2022-48978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: soc-pcm: Add NULL check in BE reparenting  Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.(CVE-2022-48992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.(CVE-2022-49002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: ops: Fix bounds check for _sx controls  For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value.(CVE-2022-49005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()  As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak.(CVE-2022-49011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/9p: Fix a potential socket leak in p9_socket_open  Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak.  This patch adds sock_release() to fix the leak issue.(CVE-2022-49020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: phy: fix null-ptr-deref while probe() failed  I got a null-ptr-deref report as following when doing fault injection test:  BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace:  \u0026lt;TASK\u0026gt;  klist_remove+0xf1/0x1c0  device_release_driver_internal+0x23e/0x2d0  bus_remove_device+0x1bd/0x240  device_del+0x357/0x770  phy_device_remove+0x11/0x30  mdiobus_unregister+0xa5/0x140  release_nodes+0x6a/0xa0  devres_release_all+0xf8/0x150  device_unbind_cleanup+0x19/0xd0  //probe path: phy_device_register()   device_add()  phy_connect   phy_attach_direct() //set device driver     probe() //it\u0026apos;s failed, driver is not bound     device_bind_driver() // probe failed, it\u0026apos;s not called  //remove path: phy_device_remove()   device_del()     device_release_driver_internal()       __device_release_driver() //dev-\u0026gt;drv is not NULL         klist_remove() \u0026lt;- knode_driver is not added yet, cause null-ptr-deref  In phy_attach_direct(), after setting the \u0026apos;dev-\u0026gt;driver\u0026apos;, probe() fails, device_bind_driver() is not called, so the knode_driver-\u0026gt;n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev-\u0026gt;driver to NULL in the error path in phy_attach_direct().(CVE-2022-49021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4403: Fix oob read in afe4403_read_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279  Call Trace:  afe4403_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4403_channel_leds+0x18/0xffffffffffffe9e0  This issue can be reproduced by singe command:   $ cat /sys/bus/spi/devices/spi0.0/iio\\:device0/in_intensity6_raw  The array size of afe4403_channel_leds is less than channels, so access with chan-\u0026gt;address cause OOB read in afe4403_read_raw. Fix it by moving access before use it.(CVE-2022-49031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278  Call Trace:  afe4404_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4404_channel_leds+0x18/0xffffffffffffe9c0  This issue can be reproduce by singe command:   $ cat /sys/bus/i2c/devices/0-0058/iio\\:device0/in_intensity6_raw  The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan-\u0026gt;address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them.(CVE-2022-49032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\u0026quot;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn\u0026apos;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn\u0026apos;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  \u0026lt;TASK\u0026gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  \u0026lt;/TASK\u0026gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error  Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.(CVE-2024-47697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  \u0026lt;/TASK\u0026gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from \u0026quot;ModelName\u0026quot;, a string that was previously parsed out of    some descriptor (\u0026quot;Vital Product Data\u0026quot;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-\u0026gt;hwinfo, \u0026quot;nffw.partno\u0026quot;), which I    think parses some descriptor that was read from the device.    (But this case likely isn\u0026apos;t exploitable because the format string looks    like \u0026quot;netronome/nic_%s\u0026quot;, and there shouldn\u0026apos;t be any *folders* starting    with \u0026quot;netronome/nic_\u0026quot;. The previous case was different because there,    the \u0026quot;%s\u0026quot; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing \u0026quot;..\u0026quot; path components.  For what it\u0026apos;s worth, I went looking and haven\u0026apos;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  resource: fix region_intersects() vs add_memory_driver_managed()  On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.  490000000-50fffffff : CXL Window 0   490000000-50fffffff : region0     490000000-50fffffff : dax0.0       490000000-50fffffff : System RAM (kmem)  Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \u0026quot;System RAM (kmem)\u0026quot; a descendant of \u0026quot;CXL Window X\u0026quot;.  This confuses region_intersects(), which expects all \u0026quot;System RAM\u0026quot; resources to be at the top level of iomem_resource.  This can lead to bugs.  For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,   $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1  dd: error writing \u0026apos;/dev/mem\u0026apos;: Bad address  1+0 records in  0+0 records out  0 bytes copied, 0.0283507 s, 0.0 kB/s  the command fails as expected.  However, the error code is wrong.  It should be \u0026quot;Operation not permitted\u0026quot; instead of \u0026quot;Bad address\u0026quot;.  More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly.  Although the accessing is prevented later because ioremap() isn\u0026apos;t allowed to map system RAM, it is a potential security issue.  During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.   ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff  WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d  Call Trace:   memremap+0xcb/0x184   xlate_dev_mem_ptr+0x25/0x2f   write_mem+0x94/0xfb   vfs_write+0x128/0x26d   ksys_write+0xac/0xfe   do_syscall_64+0x9a/0xfd   entry_SYSCALL_64_after_hwframe+0x4b/0x53  The details of command execution process are as follows.  In the above resource tree, \u0026quot;System RAM\u0026quot; is a descendant of \u0026quot;CXL Window 0\u0026quot; instead of a top level resource.  So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources.  Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly.  Fortunately, ioremap() doesn\u0026apos;t allow to map System RAM and reject the access.  So, region_intersects() needs to be fixed to work correctly with the resource tree with \u0026quot;System RAM\u0026quot; not at top level as above.  To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources.  So, we will not miss any matched resources in resource tree anymore.  In the new implementation, an example resource tree  |------------- \u0026quot;CXL Window 0\u0026quot; ------------| |-- \u0026quot;System RAM\u0026quot; --|  will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ),  |-- \u0026quot;System RAM\u0026quot; --||-- \u0026quot;CXL Window 0a\u0026quot; --|  Where \u0026quot;CXL Window 0a\u0026quot; is part of the original \u0026quot;CXL Window 0\u0026quot; that isn\u0026apos;t covered by \u0026quot;System RAM\u0026quot;.(CVE-2024-49878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don\u0026apos;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth \u0026gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-\u0026gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-\u0026gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-\u0026gt;p_depth = 0        |    brelse(path[1].p_bh)  ---\u0026gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-\u0026gt;p_depth = 1              read_extent_tree_block  ---\u0026gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-\u0026gt;p_depth == 1                  brelse(path[1].p_bh)  ---\u0026gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  \u0026lt;TASK\u0026gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we\u0026apos;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth \u0026gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  \u0026lt;TASK\u0026gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-\u0026gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since \u0026apos;path\u0026apos; is only used in ext4_ext_show_leaf(), remove \u0026apos;path\u0026apos; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which \u0026amp;fbi-\u0026gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the \u0026amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-\u0026gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-\u0026gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-\u0026gt;lcd_power(on, \u0026amp;fbi-\u0026gt;fb.var)                                    | //use fbi-\u0026gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-\u0026gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:488  kasan_report+0xd9/0x110 mm/kasan/report.c:601  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-\u0026gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-\u0026gt;sys_err_done to make sync work. The core-\u0026gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer  Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() \u0026apos;media_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;media_name\u0026apos; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() \u0026apos;if_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;if_name\u0026apos; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (\u0026quot;[TIPC] Initial merge\u0026quot;)  Compile tested only.(CVE-2024-49995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \u0026quot;uart_port_dtr_rts(uport, false);\u0026quot; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tty: n_gsm: Fix use-after-free in gsm_cleanup_mux  BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace:  \u0026lt;TASK\u0026gt;  gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]  __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389  update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500  __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846  __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107  __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]  ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195  ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79  __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338  __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  Allocated by task 65:  gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]  gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]  gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]  gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]  tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391  tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39  flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445  process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229  worker_thread+0x3dc/0x950 kernel/workqueue.c:3391  kthread+0x2a3/0x370 kernel/kthread.c:389  ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257  Freed by task 3367:  kfree+0x126/0x420 mm/slub.c:4580  gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)",
  "id": "OESA-2024-2370",
  "modified": "2026-08-06T11:07:50Z",
  "published": "2024-11-08T11:07:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2370"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48948"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48962"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48971"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48992"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49005"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49011"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49020"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49031"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47669"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47696"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47697"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49881"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49950"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49991"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50033"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50073"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48948",
    "CVE-2022-48949",
    "CVE-2022-48960",
    "CVE-2022-48962",
    "CVE-2022-48966",
    "CVE-2022-48971",
    "CVE-2022-48972",
    "CVE-2022-48978",
    "CVE-2022-48992",
    "CVE-2022-49002",
    "CVE-2022-49005",
    "CVE-2022-49011",
    "CVE-2022-49020",
    "CVE-2022-49021",
    "CVE-2022-49031",
    "CVE-2022-49032",
    "CVE-2024-47659",
    "CVE-2024-47669",
    "CVE-2024-47696",
    "CVE-2024-47697",
    "CVE-2024-47701",
    "CVE-2024-47742",
    "CVE-2024-49860",
    "CVE-2024-49877",
    "CVE-2024-49878",
    "CVE-2024-49881",
    "CVE-2024-49882",
    "CVE-2024-49883",
    "CVE-2024-49884",
    "CVE-2024-49889",
    "CVE-2024-49924",
    "CVE-2024-49936",
    "CVE-2024-49950",
    "CVE-2024-49981",
    "CVE-2024-49991",
    "CVE-2024-49995",
    "CVE-2024-50033",
    "CVE-2024-50035",
    "CVE-2024-50058",
    "CVE-2024-50073"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.100.0.181.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.100.0.181.oe2203sp1"
            }
          ],
          "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:  ipv6: avoid use-after-free in ip6_fragment()  Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.  It seems to not be always true, at least for UDP stack.  syzbot reported:  BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline] BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618  CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106  print_address_description mm/kasan/report.c:284 [inline]  print_report+0x15e/0x45d mm/kasan/report.c:395  kasan_report+0xbf/0x1f0 mm/kasan/report.c:495  ip6_dst_idev include/net/ip6_fib.h:245 [inline]  ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951  __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]  ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206  NF_HOOK_COND include/linux/netfilter.h:291 [inline]  ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227  dst_output include/net/dst.h:445 [inline]  ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161  ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966  udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286  udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313  udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606  inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665  sock_sendmsg_nosec net/socket.c:714 [inline]  sock_sendmsg+0xd3/0x120 net/socket.c:734  sock_write_iter+0x295/0x3d0 net/socket.c:1108  call_write_iter include/linux/fs.h:2191 [inline]  new_sync_write fs/read_write.c:491 [inline]  vfs_write+0x9ed/0xdd0 fs/read_write.c:584  ksys_write+0x1ec/0x250 fs/read_write.c:637  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000  \u0026lt;/TASK\u0026gt;  Allocated by task 7618:  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45  kasan_set_track+0x25/0x30 mm/kasan/common.c:52  __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325  kasan_slab_alloc include/linux/kasan.h:201 [inline]  slab_post_alloc_hook mm/slab.h:737 [inline]  slab_alloc_node mm/slub.c:3398 [inline]  slab_alloc mm/slub.c:3406 [inline]  __kmem_cache_alloc_lru mm/slub.c:3413 [inline]  kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422  dst_alloc+0x14a/0x1f0 net/core/dst.c:92  ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344  ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]  rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]  ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254  pol_lookup_func include/net/ip6_fib.h:582 [inline]  fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121  ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625  ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638  ip6_route_output include/net/ip6_route.h:98 [inline]  ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092  ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222  ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260  udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554  inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665  sock_sendmsg_nosec n ---truncated---(CVE-2022-48956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ethernet: aeroflex: fix potential skb leak in greth_init_rings()  The greth_init_rings() function won\u0026apos;t free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.  Compile tested only.(CVE-2022-48958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hix5hd2_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hisi_femac_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: mvneta: Prevent out of bounds read in mvneta_config_rss()  The pp-\u0026gt;indir[0] value comes from the user.  It is passed to:   if (cpu_online(pp-\u0026gt;rxq_def))  inside the mvneta_percpu_elect() function.  It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.(CVE-2022-48966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()  Kernel fault injection test reports null-ptr-deref as follows:  BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace:  \u0026lt;TASK\u0026gt;  raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87  call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944  unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982  unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879  register_netdevice+0x9a8/0xb90 net/core/dev.c:10083  ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659  ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229  mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316  ieee802154_if_add() allocates wpan_dev as netdev\u0026apos;s private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref.  Use INIT_LIST_HEAD() on it to initialize it correctly.(CVE-2022-48972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm \u0026quot;python3\u0026quot;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_add_data_with_key  gcdev_register() \u0026amp; gcdev_unregister() would call device_add() \u0026amp; device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.  However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().  Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.  Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().  While at it, fix another subtle issue, i.e. when gc-\u0026gt;ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It\u0026apos;s not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev-\u0026gt;descs variable.(CVE-2022-48975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/shmem-helper: Remove errant put in error path  drm_gem_shmem_mmap() doesn\u0026apos;t own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free.(CVE-2022-48981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Fix crash when replugging CSR fake controllers  It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic:  [   71.986122] Call Trace: [   71.986124]  \u0026lt;TASK\u0026gt; [   71.986125]  blocking_notifier_chain_register+0x33/0x60 [   71.986130]  hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [   71.986154]  btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [   71.986159]  ? __pm_runtime_set_status+0x1a9/0x300 [   71.986162]  ? ktime_get_mono_fast_ns+0x3e/0x90 [   71.986167]  usb_probe_interface+0xe3/0x2b0 [   71.986171]  really_probe+0xdb/0x380 [   71.986174]  ? pm_runtime_barrier+0x54/0x90 [   71.986177]  __driver_probe_device+0x78/0x170 [   71.986180]  driver_probe_device+0x1f/0x90 [   71.986183]  __device_attach_driver+0x89/0x110 [   71.986186]  ? driver_allows_async_probing+0x70/0x70 [   71.986189]  bus_for_each_drv+0x8c/0xe0 [   71.986192]  __device_attach+0xb2/0x1e0 [   71.986195]  bus_probe_device+0x92/0xb0 [   71.986198]  device_add+0x422/0x9a0 [   71.986201]  ? sysfs_merge_group+0xd4/0x110 [   71.986205]  usb_set_configuration+0x57a/0x820 [   71.986208]  usb_generic_driver_probe+0x4f/0x70 [   71.986211]  usb_probe_device+0x3a/0x110 [   71.986213]  really_probe+0xdb/0x380 [   71.986216]  ? pm_runtime_barrier+0x54/0x90 [   71.986219]  __driver_probe_device+0x78/0x170 [   71.986221]  driver_probe_device+0x1f/0x90 [   71.986224]  __device_attach_driver+0x89/0x110 [   71.986227]  ? driver_allows_async_probing+0x70/0x70 [   71.986230]  bus_for_each_drv+0x8c/0xe0 [   71.986232]  __device_attach+0xb2/0x1e0 [   71.986235]  bus_probe_device+0x92/0xb0 [   71.986237]  device_add+0x422/0x9a0 [   71.986239]  ? _dev_info+0x7d/0x98 [   71.986242]  ? blake2s_update+0x4c/0xc0 [   71.986246]  usb_new_device.cold+0x148/0x36d [   71.986250]  hub_event+0xa8a/0x1910 [   71.986255]  process_one_work+0x1c4/0x380 [   71.986259]  worker_thread+0x51/0x390 [   71.986262]  ? rescuer_thread+0x3b0/0x3b0 [   71.986264]  kthread+0xdb/0x110 [   71.986266]  ? kthread_complete_and_exit+0x20/0x20 [   71.986268]  ret_from_fork+0x1f/0x30 [   71.986273]  \u0026lt;/TASK\u0026gt; [   71.986274] ---[ end trace 0000000000000000 ]--- [   71.986284] btusb: probe of 2-1.6:1.0 failed with error -17(CVE-2022-48982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: soc-pcm: Add NULL check in BE reparenting  Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.(CVE-2022-48992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()  There is a kmemleak when test the raydium_i2c_ts with bpf mock device:    unreferenced object 0xffff88812d3675a0 (size 8):     comm \u0026quot;python3\u0026quot;, pid 349, jiffies 4294741067 (age 95.695s)     hex dump (first 8 bytes):       11 0e 10 c0 01 00 04 00                          ........     backtrace:       [\u0026lt;0000000068427125\u0026gt;] __kmalloc+0x46/0x1b0       [\u0026lt;0000000090180f91\u0026gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]       [\u0026lt;000000006e631aee\u0026gt;] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]       [\u0026lt;00000000dc6fcf38\u0026gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]       [\u0026lt;00000000a310de16\u0026gt;] i2c_device_probe+0x651/0x680       [\u0026lt;00000000f5a96bf3\u0026gt;] really_probe+0x17c/0x3f0       [\u0026lt;00000000096ba499\u0026gt;] __driver_probe_device+0xe3/0x170       [\u0026lt;00000000c5acb4d9\u0026gt;] driver_probe_device+0x49/0x120       [\u0026lt;00000000264fe082\u0026gt;] __device_attach_driver+0xf7/0x150       [\u0026lt;00000000f919423c\u0026gt;] bus_for_each_drv+0x114/0x180       [\u0026lt;00000000e067feca\u0026gt;] __device_attach+0x1e5/0x2d0       [\u0026lt;0000000054301fc2\u0026gt;] bus_probe_device+0x126/0x140       [\u0026lt;00000000aad93b22\u0026gt;] device_add+0x810/0x1130       [\u0026lt;00000000c086a53f\u0026gt;] i2c_new_client_device+0x352/0x4e0       [\u0026lt;000000003c2c248c\u0026gt;] of_i2c_register_device+0xf1/0x110       [\u0026lt;00000000ffec4177\u0026gt;] of_i2c_notify+0x100/0x160   unreferenced object 0xffff88812d3675c8 (size 8):     comm \u0026quot;python3\u0026quot;, pid 349, jiffies 4294741070 (age 95.692s)     hex dump (first 8 bytes):       22 00 36 2d 81 88 ff ff                          \u0026quot;.6-....     backtrace:       [\u0026lt;0000000068427125\u0026gt;] __kmalloc+0x46/0x1b0       [\u0026lt;0000000090180f91\u0026gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]       [\u0026lt;000000001d5c9620\u0026gt;] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]       [\u0026lt;00000000dc6fcf38\u0026gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]       [\u0026lt;00000000a310de16\u0026gt;] i2c_device_probe+0x651/0x680       [\u0026lt;00000000f5a96bf3\u0026gt;] really_probe+0x17c/0x3f0       [\u0026lt;00000000096ba499\u0026gt;] __driver_probe_device+0xe3/0x170       [\u0026lt;00000000c5acb4d9\u0026gt;] driver_probe_device+0x49/0x120       [\u0026lt;00000000264fe082\u0026gt;] __device_attach_driver+0xf7/0x150       [\u0026lt;00000000f919423c\u0026gt;] bus_for_each_drv+0x114/0x180       [\u0026lt;00000000e067feca\u0026gt;] __device_attach+0x1e5/0x2d0       [\u0026lt;0000000054301fc2\u0026gt;] bus_probe_device+0x126/0x140       [\u0026lt;00000000aad93b22\u0026gt;] device_add+0x810/0x1130       [\u0026lt;00000000c086a53f\u0026gt;] i2c_new_client_device+0x352/0x4e0       [\u0026lt;000000003c2c248c\u0026gt;] of_i2c_register_device+0xf1/0x110       [\u0026lt;00000000ffec4177\u0026gt;] of_i2c_notify+0x100/0x160  After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed.(CVE-2022-48995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  riscv: Sync efi page table\u0026apos;s kernel mappings before switching  The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic.  Fix that by updating the efi kernel mappings before switching to the efi page table.(CVE-2022-49004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: ops: Fix bounds check for _sx controls  For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value.(CVE-2022-49005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()  As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak.(CVE-2022-49011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: re-fetch skb cb after tipc_msg_validate  As the call trace shows, the original skb was freed in tipc_msg_validate(), and dereferencing the old skb cb would cause an use-after-free crash.    BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]   Call Trace:    \u0026lt;IRQ\u0026gt;    tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]    tipc_crypto_rcv+0xd32/0x1ec0 [tipc]    tipc_rcv+0x744/0x1150 [tipc]   ...   Allocated by task 47078:    kmem_cache_alloc_node+0x158/0x4d0    __alloc_skb+0x1c1/0x270    tipc_buf_acquire+0x1e/0xe0 [tipc]    tipc_msg_create+0x33/0x1c0 [tipc]    tipc_link_build_proto_msg+0x38a/0x2100 [tipc]    tipc_link_timeout+0x8b8/0xef0 [tipc]    tipc_node_timeout+0x2a1/0x960 [tipc]    call_timer_fn+0x2d/0x1c0   ...   Freed by task 47078:    tipc_msg_validate+0x7b/0x440 [tipc]    tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]    tipc_crypto_rcv+0xd32/0x1ec0 [tipc]    tipc_rcv+0x744/0x1150 [tipc]  This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipc_msg_validate().(CVE-2022-49017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/9p: Fix a potential socket leak in p9_socket_open  Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak.  This patch adds sock_release() to fix the leak issue.(CVE-2022-49020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: phy: fix null-ptr-deref while probe() failed  I got a null-ptr-deref report as following when doing fault injection test:  BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace:  \u0026lt;TASK\u0026gt;  klist_remove+0xf1/0x1c0  device_release_driver_internal+0x23e/0x2d0  bus_remove_device+0x1bd/0x240  device_del+0x357/0x770  phy_device_remove+0x11/0x30  mdiobus_unregister+0xa5/0x140  release_nodes+0x6a/0xa0  devres_release_all+0xf8/0x150  device_unbind_cleanup+0x19/0xd0  //probe path: phy_device_register()   device_add()  phy_connect   phy_attach_direct() //set device driver     probe() //it\u0026apos;s failed, driver is not bound     device_bind_driver() // probe failed, it\u0026apos;s not called  //remove path: phy_device_remove()   device_del()     device_release_driver_internal()       __device_release_driver() //dev-\u0026gt;drv is not NULL         klist_remove() \u0026lt;- knode_driver is not added yet, cause null-ptr-deref  In phy_attach_direct(), after setting the \u0026apos;dev-\u0026gt;driver\u0026apos;, probe() fails, device_bind_driver() is not called, so the knode_driver-\u0026gt;n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev-\u0026gt;driver to NULL in the error path in phy_attach_direct().(CVE-2022-49021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: fix buffer overflow in elem comparison  For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length.(CVE-2022-49023)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4403: Fix oob read in afe4403_read_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279  Call Trace:  afe4403_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4403_channel_leds+0x18/0xffffffffffffe9e0  This issue can be reproduced by singe command:   $ cat /sys/bus/spi/devices/spi0.0/iio\\:device0/in_intensity6_raw  The array size of afe4403_channel_leds is less than channels, so access with chan-\u0026gt;address cause OOB read in afe4403_read_raw. Fix it by moving access before use it.(CVE-2022-49031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278  Call Trace:  afe4404_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4404_channel_leds+0x18/0xffffffffffffe9c0  This issue can be reproduce by singe command:   $ cat /sys/bus/i2c/devices/0-0058/iio\\:device0/in_intensity6_raw  The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan-\u0026gt;address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them.(CVE-2022-49032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg_write_event_control(): fix a user-triggerable oops\r\n\r\nwe are *not* guaranteed that anything past the terminating NUL\nis mapped (let alone initialized with anything sane).(CVE-2024-45021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix a potential NULL pointer dereference\r\n\r\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\r\n\r\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\r\n\r\n(I found this bug during code inspection.)(CVE-2024-46677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check BIOS images before it is used\r\n\r\nBIOS images may fail to load and null checks are added before they are\nused.\r\n\r\nThis fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfsnotify: clear PARENT_WATCHED flags lazily\r\n\r\nIn some setups directories can have many (usually negative) dentries.\nHence __fsnotify_update_child_dentry_flags() function can take a\nsignificant amount of time. Since the bulk of this function happens\nunder inode-\u0026gt;i_lock this causes a significant contention on the lock\nwhen we remove the watch from the directory as the\n__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()\nraces with __fsnotify_update_child_dentry_flags() calls from\n__fsnotify_parent() happening on children. This can lead upto softlockup\nreports reported by users.\r\n\r\nFix the problem by calling fsnotify_update_children_dentry_flags() to\nset PARENT_WATCHED flags only when parent starts watching children.\r\n\r\nWhen parent stops watching children, clear false positive PARENT_WATCHED\nflags lazily in __fsnotify_parent() for each accessed child.(CVE-2024-47660)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\r\n\r\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we\u0026apos;ll\nstill have a preallocated node that might be used later.\r\n\r\nIf we then use that node for a new non-root node, it\u0026apos;ll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.(CVE-2024-47668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: pause TCM when the firmware is stopped\r\n\r\nNot doing so will make us send a host command to the transport while the\nfirmware is not alive, which will trigger a WARNING.\r\n\r\nbad state = 0\nWARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nRIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]\n iwl_mvm_config_scan+0x198/0x260 [iwlmvm]\n iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]\n iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]\n process_one_work+0x29e/0x640\n worker_thread+0x2df/0x690\n ? rescuer_thread+0x540/0x540\n kthread+0x192/0x1e0\n ? set_kthread_struct+0x90/0x90\n ret_from_fork+0x22/0x30(CVE-2024-47673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: get rid of online repaire on corrupted directory  syzbot reports a f2fs bug as below:  kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace:  evict+0x532/0x950 fs/inode.c:704  dispose_list fs/inode.c:747 [inline]  evict_inodes+0x5f9/0x690 fs/inode.c:797  generic_shutdown_super+0x9d/0x2d0 fs/super.c:627  kill_block_super+0x44/0x90 fs/super.c:1696  kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898  deactivate_locked_super+0xc4/0x130 fs/super.c:473  cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373  task_work_run+0x24f/0x310 kernel/task_work.c:228  ptrace_notify+0x2d2/0x380 kernel/signal.c:2402  ptrace_report_syscall include/linux/ptrace.h:415 [inline]  ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]  syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173  syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]  __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]  syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218  do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896  Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic.  Let\u0026apos;s get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The root cause is below race condition, it may cause use-after-free issue in sbi-\u0026gt;gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th)     - f2fs_ioc_shutdown      - f2fs_do_shutdown       - f2fs_stop_gc_thread        - kthread_stop(gc_th-\u0026gt;f2fs_gc_task)    : sbi-\u0026gt;gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb-\u0026gt;s_umount semaphore for fixing. - for f2fs_shutdown() path, it\u0026apos;s safe since caller has already grabbed sb-\u0026gt;s_umount semaphore.(CVE-2024-47691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u0026lt;0f\u0026gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\u0026quot;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn\u0026apos;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn\u0026apos;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  \u0026lt;TASK\u0026gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  \u0026lt;/TASK\u0026gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()  Patch series \u0026quot;nilfs2: fix potential issues with empty b-tree nodes\u0026quot;.  This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot.   This patch (of 3):  If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().  This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called.  Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency.  Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  \u0026lt;/TASK\u0026gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  block: fix potential invalid pointer dereference in blk_add_partition  The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer.  This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.(CVE-2024-47705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix out-of-bounds in dbNextAG() and diAlloc()  In dbNextAG() , there is no check for the case where bmp-\u0026gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount().  And in dbNextAG(), a check for the case where agpref is greater than bmp-\u0026gt;db_numag should be added, so an out-of-bounds exception should be prevented.  Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  padata: use integer wrap around to prevent deadlock on seq_nr overflow  When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata-\u0026gt;seq_nr and pd-\u0026gt;processed because the padata instance with overflowed seq_nr will be selected next.  To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from \u0026quot;ModelName\u0026quot;, a string that was previously parsed out of    some descriptor (\u0026quot;Vital Product Data\u0026quot;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-\u0026gt;hwinfo, \u0026quot;nffw.partno\u0026quot;), which I    think parses some descriptor that was read from the device.    (But this case likely isn\u0026apos;t exploitable because the format string looks    like \u0026quot;netronome/nic_%s\u0026quot;, and there shouldn\u0026apos;t be any *folders* starting    with \u0026quot;netronome/nic_\u0026quot;. The previous case was different because there,    the \u0026quot;%s\u0026quot; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing \u0026quot;..\u0026quot; path components.  For what it\u0026apos;s worth, I went looking and haven\u0026apos;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vhost_vdpa: assign irq bypass producer token correctly  We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don\u0026apos;t know if the token pointer is still valid or not.  Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status().  Fixing this by setting up irq bypass producer\u0026apos;s token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: keystone: Fix if-statement expression in ks_pcie_quirk()  This code accidentally uses \u0026amp;\u0026amp; where || was intended.  It potentially results in a NULL dereference.  Thus, fix the if-statement expression to use the correct condition.  [kwilczynski: commit log](CVE-2024-47756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nbd: fix race between timeout and normal completion  If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.  Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-\u0026gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption  The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table.  The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved.  Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let\u0026apos;s use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()  Since commit 3f8ca2e115e5 (\u0026quot;vhost/scsi: Extract common handling code from control queue handler\u0026quot;) a null pointer dereference bug can be triggered when guest sends an SCSI AN request.  In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `\u0026amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc-\u0026gt;req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc-\u0026gt;target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest.  When this bug occurs, the vhost_worker process is killed while holding `vq-\u0026gt;mutex` and the corresponding tpg will remain occupied indefinitely.  Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x86/0xa0  ? die_addr+0x4b/0xd0  ? exc_general_protection+0x163/0x260  ? asm_exc_general_protection+0x27/0x30  ? vhost_scsi_get_req+0x165/0x3a0  vhost_scsi_ctl_handle_vq+0x2a4/0xca0  ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10  ? __switch_to+0x721/0xeb0  ? __schedule+0xda5/0x5710  ? __kasan_check_write+0x14/0x30  ? _raw_spin_lock+0x82/0xf0  vhost_scsi_ctl_handle_kick+0x52/0x90  vhost_run_work_list+0x134/0x1b0  vhost_task_fn+0x121/0x350 ...  \u0026lt;/TASK\u0026gt; ---[ end trace 0000000000000000 ]---  Let\u0026apos;s add a check in vhost_scsi_get_req.  [whitespace fixes](CVE-2024-49863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm: omapdrm: Add missing check for alloc_ordered_workqueue  As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.(CVE-2024-49879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don\u0026apos;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth \u0026gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-\u0026gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-\u0026gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-\u0026gt;p_depth = 0        |    brelse(path[1].p_bh)  ---\u0026gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-\u0026gt;p_depth = 1              read_extent_tree_block  ---\u0026gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-\u0026gt;p_depth == 1                  brelse(path[1].p_bh)  ---\u0026gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  \u0026lt;TASK\u0026gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we\u0026apos;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth \u0026gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  \u0026lt;TASK\u0026gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-\u0026gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug  Attaching SST PCI device to VM causes \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot;. kasan report: [   19.411889] ================================================================== [   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [   19.417368] [   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10 [   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [   19.422687] Call Trace: [   19.424091]  \u0026lt;TASK\u0026gt; [   19.425448]  dump_stack_lvl+0x5d/0x80 [   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.428694]  print_report+0x19d/0x52e [   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.433539]  kasan_report+0xf0/0x170 [   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10 [   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common] [   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360 [   19.444797]  cpuhp_invoke_callback+0x221/0xec0 [   19.446337]  cpuhp_thread_fun+0x21b/0x610 [   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10 [   19.449354]  smpboot_thread_fn+0x2e7/0x6e0 [   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10 [   19.452405]  kthread+0x29c/0x350 [   19.453817]  ? __pfx_kthread+0x10/0x10 [   19.455253]  ret_from_fork+0x31/0x70 [   19.456685]  ? __pfx_kthread+0x10/0x10 [   19.458114]  ret_from_fork_asm+0x1a/0x30 [   19.459573]  \u0026lt;/TASK\u0026gt; [   19.460853] [   19.462055] Allocated by task 1198: [   19.463410]  kasan_save_stack+0x30/0x50 [   19.464788]  kasan_save_track+0x14/0x30 [   19.466139]  __kasan_kmalloc+0xaa/0xb0 [   19.467465]  __kmalloc+0x1cd/0x470 [   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common] [   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [   19.471670]  do_one_initcall+0xa4/0x380 [   19.472903]  do_init_module+0x238/0x760 [   19.474105]  load_module+0x5239/0x6f00 [   19.475285]  init_module_from_file+0xd1/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.478920]  do_syscall_64+0x82/0x160 [   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   19.481292] [   19.482205] The buggy address belongs to the object at ffff888829e65000  which belongs to the cache kmalloc-512 of size 512 [   19.484818] The buggy address is located 0 bytes to the right of  allocated 512-byte region [ffff888829e65000, ffff888829e65200) [   19.487447] [   19.488328] The buggy address belongs to the physical page: [   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [   19.493914] page_type: 0xffffffff() [   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [   19.503784] page dumped because: k ---truncated---(CVE-2024-49886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since \u0026apos;path\u0026apos; is only used in ext4_ext_show_leaf(), remove \u0026apos;path\u0026apos; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream  This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null.  The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed \u0026apos;top_pipe_to_program\u0026apos; could be null (see line 3906)(CVE-2024-49913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr and clk_mgr-\u0026gt;funcs in dcn30_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc-\u0026gt;clk_mgr` or `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is null.  The fix adds a check to ensure `dc-\u0026gt;clk_mgr` and `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed \u0026apos;dc-\u0026gt;clk_mgr\u0026apos; could be null (see line 628)(CVE-2024-49917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using them  [WHAT \u0026amp; HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again.  This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which \u0026amp;fbi-\u0026gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the \u0026amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-\u0026gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-\u0026gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-\u0026gt;lcd_power(on, \u0026amp;fbi-\u0026gt;fb.var)                                    | //use fbi-\u0026gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk_iocost: fix more out of bound shifts  Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function:  UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ...  Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name  It\u0026apos;s observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following:  ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x8d/0x190  ? do_user_addr_fault+0x2a0/0x790  ? report_bug+0x1c3/0x1d0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  ? do_user_addr_fault+0x2a0/0x790  ? exc_page_fault+0x31/0x200  exc_page_fault+0x68/0x200 \u0026lt;...snip...\u0026gt; BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  ---[ end trace 0000000000000000 ]---  BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014  RIP: 0010:dentry_name+0x1f4/0x440 \u0026lt;...snip...\u0026gt; ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130  Previously, some sanity check have been done in dump_mapping() before the print facility parsing \u0026apos;%pd\u0026apos; though, it\u0026apos;s still possible to run into an invalid dentry.d_name.name.  Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash.  Note that either retrieving the filename with \u0026apos;%pd\u0026apos; or strncpy_from_kernel_nofault(), the filename could be unreliable.(CVE-2024-49934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-\u0026gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  l2tp: prevent possible tunnel refcount underflow  When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session-\u0026gt;tunnel is non-NULL. However, session-\u0026gt;tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session-\u0026gt;tunnel is non-NULL when the tunnel refcount hasn\u0026apos;t been bumped.  Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session-\u0026gt;tunnel to get the tunnel\u0026apos;s encap. Add an encap arg to l2tp_session_set_header_len to avoid using session-\u0026gt;tunnel.  If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn\u0026apos;t yet have session-\u0026gt;tunnel set. Add a check for this case.(CVE-2024-49940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:488  kasan_report+0xd9/0x110 mm/kasan/report.c:601  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Replace pointless WARN_ON() in static_call_module_notify()  static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module().  That\u0026apos;s not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application.  A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set.  Replace it with a pr_warn().(CVE-2024-49954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: battery: Fix possible crash when unregistering a battery hook  When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash.  Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().(CVE-2024-49955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: reserve space for inline xattr before attaching reflink tree  One of our customers reported a crash and a corrupted ocfs2 filesystem.  The crash was due to the detection of corruption.  Upon troubleshooting, the fsck -fn output showed the below corruption  [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227.  Clamp the next record value? n  The stat output from the debugfs.ocfs2 showed the following corruption where the \u0026quot;Next Free Rec:\u0026quot; had overshot the \u0026quot;Count:\u0026quot; in the root metadata block.          Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)         FS Generation: 904309833 (0x35e6ac49)         CRC32: 00000000   ECC: 0000         Type: Regular   Attr: 0x0   Flags: Valid         Dynamic Features: (0x16) HasXattr InlineXattr Refcounted         Extended Attributes Block: 0  Extended Attributes Inline Size: 256         User: 0 (root)   Group: 0 (root)   Size: 281320357888         Links: 1   Clusters: 141738         ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024         atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024         mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024         dtime: 0x0 -- Wed Dec 31 17:00:00 1969         Refcount Block: 2777346         Last Extblk: 2886943   Orphan Slot: 0         Sub Alloc Slot: 0   Sub Alloc Bit: 14         Tree Depth: 1   Count: 227   Next Free Rec: 230         ## Offset        Clusters       Block#         0  0             2310           2776351         1  2310          2139           2777375         2  4449          1221           2778399         3  5670          731            2779423         4  6401          566            2780447         .......          ....           .......         .......          ....           .......  The issue was in the reflink workfow while reserving space for inline xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the time this function is called the reflink tree is already recreated at the destination inode from the source inode.  At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block.  It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption.  The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  r8169: add tally counter fields added with RTL8125  RTL8125 added fields to the tally counter, what may result in the chip dma\u0026apos;ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobes: fix kernel info leak via \u0026quot;[uprobes]\u0026quot; vma  xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn\u0026apos;t really matter, debugger can read this memory anyway.(CVE-2024-49975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gso: fix udp gso fraglist segmentation after pull from frag_list  Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly.  Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size  Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants.  In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg-\u0026gt;next)-\u0026gt;dest.  Detect invalid geometry due to pull, by checking head_skb size. Don\u0026apos;t just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-\u0026gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-\u0026gt;sys_err_done to make sync work. The core-\u0026gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/stm: Avoid use-after-free issues with crtc and plane  ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1].  Use allocations managed by the DRM framework.  Found by Linux Verification Center (linuxtesting.org).  [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() \u0026apos;media_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;media_name\u0026apos; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() \u0026apos;if_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;if_name\u0026apos; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (\u0026quot;[TIPC] Initial merge\u0026quot;)  Compile tested only.(CVE-2024-49995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cifs: Fix buffer overflow when parsing NFS reparse points  ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType\u0026apos;s size from ReparseDataLength.  Function cifs_strndup_from_utf16() is currentlly accessing buf-\u0026gt;DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.  Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.  Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().(CVE-2024-49996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()  Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`.  With this, fix the following warning:  elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \u0026quot;ext_scan-\u0026gt;tlv_buffer\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex](CVE-2024-50008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: dax: fix overflowing extents beyond inode size when partially writing  The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as:  dd if=/dev/urandom of=file bs=4M count=1  dax_iomap_rw   iomap_iter // round 1    ext4_iomap_begin     ext4_iomap_alloc // allocate 0~2M extents(written flag)   dax_iomap_iter // copy 2M data   iomap_iter // round 2    iomap_iter_advance     iter-\u0026gt;pos += iter-\u0026gt;processed // iter-\u0026gt;pos = 2M    ext4_iomap_begin     ext4_iomap_alloc // allocate 2~4M extents(written flag)   dax_iomap_iter    fatal_signal_pending   done = iter-\u0026gt;pos - iocb-\u0026gt;ki_pos // done = 2M  ext4_handle_inode_extension   ext4_update_inode_size // inode size = 2M  fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?  Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid overflow assignment in link_dp_cts  sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t.  Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4.  This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF in async decryption  Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API.  Reproducer:     # mount.cifs -o ...,seal,esize=1 //srv/share /mnt     # dd if=/mnt/largefile of=/dev/null     ...     [  194.196391] ==================================================================     [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110     [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899     [  194.197707]     [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43     [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014     [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]     [  194.200032] Call Trace:     [  194.200191]  \u0026lt;TASK\u0026gt;     [  194.200327]  dump_stack_lvl+0x4e/0x70     [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110     [  194.200809]  print_report+0x174/0x505     [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10     [  194.201352]  ? srso_return_thunk+0x5/0x5f     [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0     [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202128]  kasan_report+0xc8/0x150     [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202616]  gf128mul_4k_lle+0xc1/0x110     [  194.202863]  ghash_update+0x184/0x210     [  194.203103]  shash_ahash_update+0x184/0x2a0     [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10     [  194.203651]  ? srso_return_thunk+0x5/0x5f     [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340     [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140     [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]     [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]     [  194.208507]  ? srso_return_thunk+0x5/0x5f     [  194.209205]  ? srso_return_thunk+0x5/0x5f     [  194.209925]  ? srso_return_thunk+0x5/0x5f     [  194.210443]  ? srso_return_thunk+0x5/0x5f     [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]     [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]     [  194.214670]  ? srso_return_thunk+0x5/0x5f     [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]  This is because TFM is being used in parallel.  Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()).  Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it\u0026apos;s always going to be a synchronous operation.(CVE-2024-50047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \u0026quot;uart_port_dtr_rts(uport, false);\u0026quot; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition  In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then \u0026amp;sndev-\u0026gt;check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work.  If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                 CPU1                          | check_link_status_work switchtec_ntb_remove    | kfree(sndev);           |                         | if (sndev-\u0026gt;link_force_down)                         | // use sndev  Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.(CVE-2024-50059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring: check if we need to reschedule during overflow flush  In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it\u0026apos;ll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.  Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There\u0026apos;s no state to maintain here as overflows always prune from head-of-list, hence it\u0026apos;s fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tail call between progs attached to different hooks  bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed.  For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2\u0026apos;s prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed.  Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2\u0026apos;s return value 1 will be used as the return value for prog1\u0026apos;s hook file_alloc_security. That is, the return value rule is bypassed.  This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won\u0026apos;t check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include \u0026lt;stdio.h\u0026gt; \\#include \u0026lt;stdlib.h\u0026gt; \\#include \u0026lt;string.h\u0026gt;  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i \u0026lt; n; ++i)     {         char c = i % 26 + \u0026apos;a\u0026apos;;         str[i] = c;     }     str[n-1] = \u0026apos;\\0\u0026apos;; }  void print_string(char *str) {     printf(\u0026quot;%s\\n\u0026quot;, str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \u0026quot;p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\u0026quot;  \u0026gt; uprobe_events echo 1 \u0026gt; events/uprobes/enable echo 1 \u0026gt; tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  \u0026lt;/TASK\u0026gt;  This commit enforces the buffer\u0026apos;s maxlen less than a page-size to avoid store_trace_args() out-of-memory access.(CVE-2024-50067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  parport: Proper fix for array out-of-bounds access  The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf().  However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.  Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: fix mptcp DSS corruption due to large pmtu xmit  Syzkaller was able to trigger a DSS corruption:    TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Modules linked in:   CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024   RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 \u0026lt;0f\u0026gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff   RSP: 0018:ffffc90000006db8 EFLAGS: 00010246   RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00   RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0   RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8   R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000   R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5   FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   Call Trace:    \u0026lt;IRQ\u0026gt;    move_skbs_to_msk net/mptcp/protocol.c:811 [inline]    mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854    subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490    tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283    tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350    ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205    ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    __netif_receive_skb_one_core net/core/dev.c:5662 [inline]    __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775    process_backlog+0x662/0x15b0 net/core/dev.c:6107    __napi_poll+0xcb/0x490 net/core/dev.c:6771    napi_poll net/core/dev.c:6840 [inline]    net_rx_action+0x89b/0x1240 net/core/dev.c:6962    handle_softirqs+0x2c5/0x980 kernel/softirq.c:554    do_softirq+0x11b/0x1e0 kernel/softirq.c:455    \u0026lt;/IRQ\u0026gt;    \u0026lt;TASK\u0026gt;    __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382    local_bh_enable include/linux/bottom_half.h:33 [inline]    rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]    __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451    dev_queue_xmit include/linux/netdevice.h:3094 [inline]    neigh_hh_output include/net/neighbour.h:526 [inline]    neigh_output include/net/neighbour.h:540 [inline]    ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236    ip_local_out net/ipv4/ip_output.c:130 [inline]    __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536    __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466    tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]    tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]    tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752    __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015    tcp_push_pending_frames include/net/tcp.h:2107 [inline]    tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]    tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    sk_backlog_rcv include/net/sock.h:1113 [inline]    __release_sock+0x214/0x350 net/core/sock.c:3072    release_sock+0x61/0x1f0 net/core/sock.c:3626    mptcp_push_ ---truncated---(CVE-2024-50083)",
  "id": "OESA-2024-2371",
  "modified": "2026-08-06T11:07:51Z",
  "published": "2024-11-08T11:07:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2371"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48960"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48962"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48966"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48992"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49004"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49005"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49011"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49020"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49023"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49031"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47660"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47668"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47690"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47691"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47696"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47699"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47703"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47705"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47723"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47748"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49881"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49882"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49889"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49913"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49933"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49934"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49936"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49940"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49950"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49955"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49973"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49981"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49992"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49995"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49996"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50015"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50033"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50059"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50060"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50063"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50067"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50074"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50083"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48956",
    "CVE-2022-48958",
    "CVE-2022-48960",
    "CVE-2022-48961",
    "CVE-2022-48962",
    "CVE-2022-48966",
    "CVE-2022-48972",
    "CVE-2022-48975",
    "CVE-2022-48981",
    "CVE-2022-48982",
    "CVE-2022-48992",
    "CVE-2022-48995",
    "CVE-2022-49004",
    "CVE-2022-49005",
    "CVE-2022-49011",
    "CVE-2022-49017",
    "CVE-2022-49020",
    "CVE-2022-49021",
    "CVE-2022-49023",
    "CVE-2022-49031",
    "CVE-2022-49032",
    "CVE-2024-45021",
    "CVE-2024-46677",
    "CVE-2024-46809",
    "CVE-2024-47659",
    "CVE-2024-47660",
    "CVE-2024-47668",
    "CVE-2024-47673",
    "CVE-2024-47690",
    "CVE-2024-47691",
    "CVE-2024-47692",
    "CVE-2024-47693",
    "CVE-2024-47696",
    "CVE-2024-47699",
    "CVE-2024-47701",
    "CVE-2024-47703",
    "CVE-2024-47705",
    "CVE-2024-47723",
    "CVE-2024-47739",
    "CVE-2024-47742",
    "CVE-2024-47748",
    "CVE-2024-47756",
    "CVE-2024-49855",
    "CVE-2024-49858",
    "CVE-2024-49860",
    "CVE-2024-49863",
    "CVE-2024-49877",
    "CVE-2024-49879",
    "CVE-2024-49881",
    "CVE-2024-49882",
    "CVE-2024-49883",
    "CVE-2024-49884",
    "CVE-2024-49886",
    "CVE-2024-49889",
    "CVE-2024-49913",
    "CVE-2024-49917",
    "CVE-2024-49922",
    "CVE-2024-49924",
    "CVE-2024-49933",
    "CVE-2024-49934",
    "CVE-2024-49936",
    "CVE-2024-49940",
    "CVE-2024-49950",
    "CVE-2024-49954",
    "CVE-2024-49955",
    "CVE-2024-49958",
    "CVE-2024-49965",
    "CVE-2024-49973",
    "CVE-2024-49975",
    "CVE-2024-49978",
    "CVE-2024-49981",
    "CVE-2024-49992",
    "CVE-2024-49995",
    "CVE-2024-49996",
    "CVE-2024-50008",
    "CVE-2024-50015",
    "CVE-2024-50016",
    "CVE-2024-50028",
    "CVE-2024-50033",
    "CVE-2024-50035",
    "CVE-2024-50046",
    "CVE-2024-50047",
    "CVE-2024-50058",
    "CVE-2024-50059",
    "CVE-2024-50060",
    "CVE-2024-50063",
    "CVE-2024-50067",
    "CVE-2024-50074",
    "CVE-2024-50083"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "perf-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-76.0.0.69.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-76.0.0.69.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-76.0.0.69.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "perf-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-76.0.0.69.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-76.0.0.69.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-76.0.0.69.oe2403"
            }
          ],
          "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 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\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\nblk-iocost: avoid out of bounds shift\n\nUBSAN catches undefined behavior in blk-iocost, where sometimes\niocg-\u0026gt;delay is shifted right by a number that is too large,\nresulting in undefined behavior on some architectures.\n\n[  186.556576] ------------[ cut here ]------------\nUBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23\nshift exponent 64 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;)\nCPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1\nHardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x8f/0xe0\n __ubsan_handle_shift_out_of_bounds+0x22c/0x280\n iocg_kick_delay+0x30b/0x310\n ioc_timer_fn+0x2fb/0x1f80\n __run_timer_base+0x1b6/0x250\n...\n\nAvoid that undefined behavior by simply taking the\n\u0026quot;delay = 0\u0026quot; branch if the shift is too large.\n\nI am not sure what the symptoms of an undefined value\ndelay will be, but I suspect it could be more than a\nlittle annoying to debug.(CVE-2024-36916)\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\nthermal/drivers/tsens: Fix null pointer dereference\n\ncompute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)\nas compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null\npointer dereference (if DEBUG or DYNAMIC_DEBUG set).\nFix this bug by adding null pointer check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: pcie: handle randbuf allocation failure\n\nThe kzalloc() in brcmf_pcie_download_fw_nvram() will return null\nif the physical memory has run out. As a result, if we use\nget_random_bytes() to generate random bytes in the randbuf, the\nnull pointer dereference bug will happen.\n\nIn order to prevent allocation failure, this patch adds a separate\nfunction using buffer on kernel stack to generate random bytes in\nthe randbuf, which could prevent the kernel stack from overflow.(CVE-2024-38575)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntools/nolibc/stdlib: fix memory error in realloc()\n\nPass user_p_len to memcpy() instead of heap-\u0026gt;len to prevent realloc()\nfrom copying an extra sizeof(heap) bytes from beyond the allocated\nregion.(CVE-2024-38585)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: stk1160: fix bounds checking in stk1160_copy_video()\n\nThe subtract in this condition is reversed.  The -\u0026gt;length is the length\nof the buffer.  The -\u0026gt;bytesused is how many bytes we have copied thus\nfar.  When the condition is reversed that means the result of the\nsubtraction is always negative but since it\u0026apos;s unsigned then the result\nis a very high positive value.  That means the overflow check is never\ntrue.\n\nAdditionally, the -\u0026gt;bytesused doesn\u0026apos;t actually work for this purpose\nbecause we\u0026apos;re not writing to \u0026quot;buf-\u0026gt;mem + buf-\u0026gt;bytesused\u0026quot;.  Instead, the\nmath to calculate the destination where we are writing is a bit\ninvolved.  You calculate the number of full lines already written,\nmultiply by two, skip a line if necessary so that we start on an odd\nnumbered line, and add the offset into the line.\n\nTo fix this buffer overflow, just take the actual destination where we\nare writing, if the offset is already out of bounds print an error and\nreturn.  Otherwise, write up to buf-\u0026gt;length bytes.(CVE-2024-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL\n\ncommit a421ef303008 (\u0026quot;mm: allow !GFP_KERNEL allocations for kvmalloc\u0026quot;)\nincludes support for __GFP_NOFAIL, but it presents a conflict with commit\ndd544141b9eb (\u0026quot;vmalloc: back off when the current task is OOM-killed\u0026quot;).  A\npossible scenario is as follows:\n\nprocess-a\n__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)\n    __vmalloc_area_node()\n        vm_area_alloc_pages()\n\t\t--\u0026gt; oom-killer send SIGKILL to process-a\n        if (fatal_signal_pending(current)) break;\n--\u0026gt; return NULL;\n\nTo fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()\nif __GFP_NOFAIL set.\n\nThis issue occurred during OPLUS KASAN TEST. Below is part of the log\n-\u0026gt; oom-killer sends signal to process\n[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198\n\n[65731.259685] [T32454] Call trace:\n[65731.259698] [T32454]  dump_backtrace+0xf4/0x118\n[65731.259734] [T32454]  show_stack+0x18/0x24\n[65731.259756] [T32454]  dump_stack_lvl+0x60/0x7c\n[65731.259781] [T32454]  dump_stack+0x18/0x38\n[65731.259800] [T32454]  mrdump_common_die+0x250/0x39c [mrdump]\n[65731.259936] [T32454]  ipanic_die+0x20/0x34 [mrdump]\n[65731.260019] [T32454]  atomic_notifier_call_chain+0xb4/0xfc\n[65731.260047] [T32454]  notify_die+0x114/0x198\n[65731.260073] [T32454]  die+0xf4/0x5b4\n[65731.260098] [T32454]  die_kernel_fault+0x80/0x98\n[65731.260124] [T32454]  __do_kernel_fault+0x160/0x2a8\n[65731.260146] [T32454]  do_bad_area+0x68/0x148\n[65731.260174] [T32454]  do_mem_abort+0x151c/0x1b34\n[65731.260204] [T32454]  el1_abort+0x3c/0x5c\n[65731.260227] [T32454]  el1h_64_sync_handler+0x54/0x90\n[65731.260248] [T32454]  el1h_64_sync+0x68/0x6c\n\n[65731.260269] [T32454]  z_erofs_decompress_queue+0x7f0/0x2258\n--\u0026gt; be-\u0026gt;decompressed_pages = kvcalloc(be-\u0026gt;nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);\n\tkernel panic by NULL pointer dereference.\n\terofs assume kvmalloc with __GFP_NOFAIL never return NULL.\n[65731.260293] [T32454]  z_erofs_runqueue+0xf30/0x104c\n[65731.260314] [T32454]  z_erofs_readahead+0x4f0/0x968\n[65731.260339] [T32454]  read_pages+0x170/0xadc\n[65731.260364] [T32454]  page_cache_ra_unbounded+0x874/0xf30\n[65731.260388] [T32454]  page_cache_ra_order+0x24c/0x714\n[65731.260411] [T32454]  filemap_fault+0xbf0/0x1a74\n[65731.260437] [T32454]  __do_fault+0xd0/0x33c\n[65731.260462] [T32454]  handle_mm_fault+0xf74/0x3fe0\n[65731.260486] [T32454]  do_mem_abort+0x54c/0x1b34\n[65731.260509] [T32454]  el0_da+0x44/0x94\n[65731.260531] [T32454]  el0t_64_sync_handler+0x98/0xb4\n[65731.260553] [T32454]  el0t_64_sync+0x198/0x19c(CVE-2024-39474)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix variable length array abuse in btree_iter\n\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\n\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: Fix use-after-free bug in gb_interface_release due to race condition.\n\nIn gb_interface_create, \u0026amp;intf-\u0026gt;mode_switch_completion is bound with\ngb_interface_mode_switch_work. Then it will be started by\ngb_interface_request_mode_switch. Here is the relevant code.\nif (!queue_work(system_long_wq, \u0026amp;intf-\u0026gt;mode_switch_work)) {\n\t...\n}\n\nIf we call gb_interface_release to make cleanup, there may be an\nunfinished work. This function will call kfree to free the object\n\u0026quot;intf\u0026quot;. However, if gb_interface_mode_switch_work is scheduled to\nrun after kfree, it may cause use-after-free error as\ngb_interface_mode_switch_work will use the object \u0026quot;intf\u0026quot;.\nThe possible execution flow that may lead to the issue is as follows:\n\nCPU0                            CPU1\n\n                            |   gb_interface_create\n                            |   gb_interface_request_mode_switch\ngb_interface_release        |\nkfree(intf) (free)          |\n                            |   gb_interface_mode_switch_work\n                            |   mutex_lock(\u0026amp;intf-\u0026gt;mutex) (use)\n\nFix it by canceling the work before kfree.(CVE-2024-39495)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/dpt: Make DPT object unshrinkable\n\nIn some scenarios, the DPT object gets shrunk but\nthe actual framebuffer did not and thus its still\nthere on the DPT\u0026apos;s vm-\u0026gt;bound_list. Then it tries to\nrewrite the PTEs via a stale CPU mapping. This causes panic.\n\n[vsyrjala: Add TODO comment]\n(cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)(CVE-2024-40924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngve: Clear napi-\u0026gt;skb before dev_kfree_skb_any()\n\ngve_rx_free_skb incorrectly leaves napi-\u0026gt;skb referencing an skb after it\nis freed with dev_kfree_skb_any(). This can result in a subsequent call\nto napi_get_frags returning a dangling pointer.\n\nFix this by clearing napi-\u0026gt;skb before the skb is freed.(CVE-2024-40937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: shmem: fix getting incorrect lruvec when replacing a shmem folio\n\nWhen testing shmem swapin, I encountered the warning below on my machine. \nThe reason is that replacing an old shmem folio with a new one causes\nmem_cgroup_migrate() to clear the old folio\u0026apos;s memcg data.  As a result,\nthe old folio cannot get the correct memcg\u0026apos;s lruvec needed to remove\nitself from the LRU list when it is being freed.  This could lead to\npossible serious problems, such as LRU list crashes due to holding the\nwrong LRU lock, and incorrect LRU statistics.\n\nTo fix this issue, we can fallback to use the mem_cgroup_replace_folio()\nto replace the old shmem folio.\n\n[ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960\n[ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff)\n[ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000\n[ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000\n[ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000\n[ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000\n[ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026amp;\u0026amp; !mem_cgroup_disabled())\n[ 5241.100338] ------------[ cut here ]------------\n[ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150\n[...]\n[ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150\n[ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150\n[ 5241.100376] sp : ffff80008b38b930\n[...]\n[ 5241.100398] Call trace:\n[ 5241.100399]  folio_lruvec_lock_irqsave+0x140/0x150\n[ 5241.100401]  __page_cache_release+0x90/0x300\n[ 5241.100404]  __folio_put+0x50/0x108\n[ 5241.100406]  shmem_replace_folio+0x1b4/0x240\n[ 5241.100409]  shmem_swapin_folio+0x314/0x528\n[ 5241.100411]  shmem_get_folio_gfp+0x3b4/0x930\n[ 5241.100412]  shmem_fault+0x74/0x160\n[ 5241.100414]  __do_fault+0x40/0x218\n[ 5241.100417]  do_shared_fault+0x34/0x1b0\n[ 5241.100419]  do_fault+0x40/0x168\n[ 5241.100420]  handle_pte_fault+0x80/0x228\n[ 5241.100422]  __handle_mm_fault+0x1c4/0x440\n[ 5241.100424]  handle_mm_fault+0x60/0x1f0\n[ 5241.100426]  do_page_fault+0x120/0x488\n[ 5241.100429]  do_translation_fault+0x4c/0x68\n[ 5241.100431]  do_mem_abort+0x48/0xa0\n[ 5241.100434]  el0_da+0x38/0xc0\n[ 5241.100436]  el0t_64_sync_handler+0x68/0xc0\n[ 5241.100437]  el0t_64_sync+0x14c/0x150\n[ 5241.100439] ---[ end trace 0000000000000000 ]---\n\n[baolin.wang@linux.alibaba.com: remove less helpful comments, per Matthew]\n  Link: https://lkml.kernel.org/r/ccad3fe1375b468ebca3227b6b729f3eaf9d8046.1718423197.git.baolin.wang@linux.alibaba.com(CVE-2024-40949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible NULL deref in fib6_nh_init()\n\nsyzbot reminds us that in6_dev_get() can return NULL.\n\nfib6_nh_init()\n    ip6_validate_gw(  \u0026amp;idev  )\n        ip6_route_check_nh(  idev  )\n            *idev = in6_dev_get(dev); // can be NULL\n\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]\nCPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024\n RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606\nCode: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b\nRSP: 0018:ffffc900032775a0 EFLAGS: 00010202\nRAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8\nRBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000\nR10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8\nR13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000\nFS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809\n  ip6_route_add+0x28/0x160 net/ipv6/route.c:3853\n  ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483\n  inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579\n  sock_do_ioctl+0x158/0x460 net/socket.c:1222\n  sock_ioctl+0x629/0x8e0 net/socket.c:1341\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:907 [inline]\n  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f940f07cea9(CVE-2024-40961)\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\nKVM: arm64: Disassociate vcpus from redistributor region on teardown\n\nWhen tearing down a redistributor region, make sure we don\u0026apos;t have\nany dangling pointer to that region stored in a vcpu.(CVE-2024-40989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/sqpoll: work around a potential audit memory leak\n\nkmemleak complains that there\u0026apos;s a memory leak related to connect\nhandling:\n\nunreferenced object 0xffff0001093bdf00 (size 128):\ncomm \u0026quot;iou-sqp-455\u0026quot;, pid 457, jiffies 4294894164\nhex dump (first 32 bytes):\n02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00  ................\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\nbacktrace (crc 2e481b1a):\n[\u0026lt;00000000c0a26af4\u0026gt;] kmemleak_alloc+0x30/0x38\n[\u0026lt;000000009c30bb45\u0026gt;] kmalloc_trace+0x228/0x358\n[\u0026lt;000000009da9d39f\u0026gt;] __audit_sockaddr+0xd0/0x138\n[\u0026lt;0000000089a93e34\u0026gt;] move_addr_to_kernel+0x1a0/0x1f8\n[\u0026lt;000000000b4e80e6\u0026gt;] io_connect_prep+0x1ec/0x2d4\n[\u0026lt;00000000abfbcd99\u0026gt;] io_submit_sqes+0x588/0x1e48\n[\u0026lt;00000000e7c25e07\u0026gt;] io_sq_thread+0x8a4/0x10e4\n[\u0026lt;00000000d999b491\u0026gt;] ret_from_fork+0x10/0x20\n\nwhich can can happen if:\n\n1) The command type does something on the prep side that triggers an\n   audit call.\n2) The thread hasn\u0026apos;t done any operations before this that triggered\n   an audit call inside -\u0026gt;issue(), where we have audit_uring_entry()\n   and audit_uring_exit().\n\nWork around this by issuing a blanket NOP operation before the SQPOLL\ndoes anything.(CVE-2024-41001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: check if a hash-index is in cpu_possible_mask\n\nThe problem is that there are systems where cpu_possible_mask has gaps\nbetween set CPUs, for example SPARC.  In this scenario addr_to_vb_xa()\nhash function can return an index which accesses to not-possible and not\nsetup CPU area using per_cpu() macro.  This results in an oops on SPARC.\n\nA per-cpu vmap_block_queue is also used as hash table, incorrectly\nassuming the cpu_possible_mask has no gaps.  Fix it by adjusting an index\nto a next possible CPU.(CVE-2024-41032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()\n\nThe following is emitted when using idxd (DSA) dmanegine as the data\nmover for ntb_transport that ntb_netdev uses.\n\n[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526\n[74412.556784] caller is netif_rx_internal+0x42/0x130\n[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5\n[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024\n[74412.581699] Call Trace:\n[74412.584514]  \u0026lt;TASK\u0026gt;\n[74412.586933]  dump_stack_lvl+0x55/0x70\n[74412.591129]  check_preemption_disabled+0xc8/0xf0\n[74412.596374]  netif_rx_internal+0x42/0x130\n[74412.600957]  __netif_rx+0x20/0xd0\n[74412.604743]  ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]\n[74412.610985]  ntb_complete_rxc+0xed/0x140 [ntb_transport]\n[74412.617010]  ntb_rx_copy_callback+0x53/0x80 [ntb_transport]\n[74412.623332]  idxd_dma_complete_txd+0xe3/0x160 [idxd]\n[74412.628963]  idxd_wq_thread+0x1a6/0x2b0 [idxd]\n[74412.634046]  irq_thread_fn+0x21/0x60\n[74412.638134]  ? irq_thread+0xa8/0x290\n[74412.642218]  irq_thread+0x1a0/0x290\n[74412.646212]  ? __pfx_irq_thread_fn+0x10/0x10\n[74412.651071]  ? __pfx_irq_thread_dtor+0x10/0x10\n[74412.656117]  ? __pfx_irq_thread+0x10/0x10\n[74412.660686]  kthread+0x100/0x130\n[74412.664384]  ? __pfx_kthread+0x10/0x10\n[74412.668639]  ret_from_fork+0x31/0x50\n[74412.672716]  ? __pfx_kthread+0x10/0x10\n[74412.676978]  ret_from_fork_asm+0x1a/0x30\n[74412.681457]  \u0026lt;/TASK\u0026gt;\n\nThe cause is due to the idxd driver interrupt completion handler uses\nthreaded interrupt and the threaded handler is not hard or soft interrupt\ncontext. However __netif_rx() can only be called from interrupt context.\nChange the call to netif_rx() in order to allow completion via normal\ncontext for dmaengine drivers that utilize threaded irq handling.\n\nWhile the following commit changed from netif_rx() to __netif_rx(),\nbaebdf48c360 (\u0026quot;net: dev: Makes sure netif_rx() can be invoked in any context.\u0026quot;),\nthe change should\u0026apos;ve been a noop instead. However, the code precedes this\nfix should\u0026apos;ve been using netif_rx_ni() or netif_rx_any_context().(CVE-2024-42110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: page_ref: remove folio_try_get_rcu()\n\nThe below bug was reported on a non-SMP kernel:\n\n[  275.267158][ T4335] ------------[ cut here ]------------\n[  275.267949][ T4335] kernel BUG at include/linux/page_ref.h:275!\n[  275.268526][ T4335] invalid opcode: 0000 [#1] KASAN PTI\n[  275.269001][ T4335] CPU: 0 PID: 4335 Comm: trinity-c3 Not tainted 6.7.0-rc4-00061-gefa7df3e3bb5 #1\n[  275.269787][ T4335] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n[  275.270679][ T4335] RIP: 0010:try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[  275.272813][ T4335] RSP: 0018:ffffc90005dcf650 EFLAGS: 00010202\n[  275.273346][ T4335] RAX: 0000000000000246 RBX: ffffea00066e0000 RCX: 0000000000000000\n[  275.274032][ T4335] RDX: fffff94000cdc007 RSI: 0000000000000004 RDI: ffffea00066e0034\n[  275.274719][ T4335] RBP: ffffea00066e0000 R08: 0000000000000000 R09: fffff94000cdc006\n[  275.275404][ T4335] R10: ffffea00066e0037 R11: 0000000000000000 R12: 0000000000000136\n[  275.276106][ T4335] R13: ffffea00066e0034 R14: dffffc0000000000 R15: ffffea00066e0008\n[  275.276790][ T4335] FS:  00007fa2f9b61740(0000) GS:ffffffff89d0d000(0000) knlGS:0000000000000000\n[  275.277570][ T4335] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  275.278143][ T4335] CR2: 00007fa2f6c00000 CR3: 0000000134b04000 CR4: 00000000000406f0\n[  275.278833][ T4335] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  275.279521][ T4335] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  275.280201][ T4335] Call Trace:\n[  275.280499][ T4335]  \u0026lt;TASK\u0026gt;\n[ 275.280751][ T4335] ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)\n[ 275.281087][ T4335] ? do_trap (arch/x86/kernel/traps.c:112 arch/x86/kernel/traps.c:153)\n[ 275.281463][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.281884][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.282300][ T4335] ? do_error_trap (arch/x86/kernel/traps.c:174)\n[ 275.282711][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.283129][ T4335] ? handle_invalid_op (arch/x86/kernel/traps.c:212)\n[ 275.283561][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.283990][ T4335] ? exc_invalid_op (arch/x86/kernel/traps.c:264)\n[ 275.284415][ T4335] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:568)\n[ 275.284859][ T4335] ? try_get_folio (include/linux/page_ref.h:275 (discriminator 3) mm/gup.c:79 (discriminator 3))\n[ 275.285278][ T4335] try_grab_folio (mm/gup.c:148)\n[ 275.285684][ T4335] __get_user_pages (mm/gup.c:1297 (discriminator 1))\n[ 275.286111][ T4335] ? __pfx___get_user_pages (mm/gup.c:1188)\n[ 275.286579][ T4335] ? __pfx_validate_chain (kernel/locking/lockdep.c:3825)\n[ 275.287034][ T4335] ? mark_lock (kernel/locking/lockdep.c:4656 (discriminator 1))\n[ 275.287416][ T4335] __gup_longterm_locked (mm/gup.c:1509 mm/gup.c:2209)\n[ 275.288192][ T4335] ? __pfx___gup_longterm_locked (mm/gup.c:2204)\n[ 275.288697][ T4335] ? __pfx_lock_acquire (kernel/locking/lockdep.c:5722)\n[ 275.289135][ T4335] ? __pfx___might_resched (kernel/sched/core.c:10106)\n[ 275.289595][ T4335] pin_user_pages_remote (mm/gup.c:3350)\n[ 275.290041][ T4335] ? __pfx_pin_user_pages_remote (mm/gup.c:3350)\n[ 275.290545][ T4335] ? find_held_lock (kernel/locking/lockdep.c:5244 (discriminator 1))\n[ 275.290961][ T4335] ? mm_access (kernel/fork.c:1573)\n[ 275.291353][ T4335] process_vm_rw_single_vec+0x142/0x360\n[ 275.291900][ T4335] ? __pfx_process_vm_rw_single_vec+0x10/0x10\n[ 275.292471][ T4335] ? mm_access (kernel/fork.c:1573)\n[ 275.292859][ T4335] process_vm_rw_core+0x272/0x4e0\n[ 275.293384][ T4335] ? hlock_class (a\n---truncated---(CVE-2024-42251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix null reference error when checking end of zone\n\nThis patch fixes a potentially null pointer being accessed by\nis_end_zone_blkaddr() that checks the last block of a zone\nwhen f2fs is mounted as a single device.(CVE-2024-43857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exit\n\nWhen a task is scheduled out, pending sigtrap deliveries are deferred\nto the target task upon resume to userspace via task_work.\n\nHowever failures while adding an event\u0026apos;s callback to the task_work\nengine are ignored. And since the last call for events exit happen\nafter task work is eventually closed, there is a small window during\nwhich pending sigtrap can be queued though ignored, leaking the event\nrefcount addition such as in the following scenario:\n\n    TASK A\n    -----\n\n    do_exit()\n       exit_task_work(tsk);\n\n       \u0026lt;IRQ\u0026gt;\n       perf_event_overflow()\n          event-\u0026gt;pending_sigtrap = pending_id;\n          irq_work_queue(\u0026amp;event-\u0026gt;pending_irq);\n       \u0026lt;/IRQ\u0026gt;\n    =========\u0026gt; PREEMPTION: TASK A -\u0026gt; TASK B\n       event_sched_out()\n          event-\u0026gt;pending_sigtrap = 0;\n          atomic_long_inc_not_zero(\u0026amp;event-\u0026gt;refcount)\n          // FAILS: task work has exited\n          task_work_add(\u0026amp;event-\u0026gt;pending_task)\n       [...]\n       \u0026lt;IRQ WORK\u0026gt;\n       perf_pending_irq()\n          // early return: event-\u0026gt;oncpu = -1\n       \u0026lt;/IRQ WORK\u0026gt;\n       [...]\n    =========\u0026gt; TASK B -\u0026gt; TASK A\n       perf_event_exit_task(tsk)\n          perf_event_exit_event()\n             free_event()\n                WARN(atomic_long_cmpxchg(\u0026amp;event-\u0026gt;refcount, 1, 0) != 1)\n                // leak event due to unexpected refcount == 2\n\nAs a result the event is never released while the task exits.\n\nFix this with appropriate task_work_add()\u0026apos;s error handling.(CVE-2024-43870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: endpoint: Clean up error handling in vpci_scan_bus()\n\nSmatch complains about inconsistent NULL checking in vpci_scan_bus():\n\n    drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed \u0026apos;vpci_bus\u0026apos; could be null (see line 1021)\n\nInstead of printing an error message and then crashing we should return\nan error code and clean up.\n\nAlso the NULL check is reversed so it prints an error for success\ninstead of failure.(CVE-2024-43875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup()\n\nAvoid large backtrace, it is sufficient to warn the user that there has\nbeen a link problem. Either the link has failed and the system is in need\nof maintenance, or the link continues to work and user has been informed.\nThe message from the warning can be looked up in the sources.\n\nThis makes an actual link issue less verbose.\n\nFirst of all, this controller has a limitation in that the controller\ndriver has to assist the hardware with transition to L1 link state by\nwriting L1IATN to PMCTRL register, the L1 and L0 link state switching\nis not fully automatic on this controller.\n\nIn case of an ASMedia ASM1062 PCIe SATA controller which does not support\nASPM, on entry to suspend or during platform pm_test, the SATA controller\nenters D3hot state and the link enters L1 state. If the SATA controller\nwakes up before rcar_pcie_wakeup() was called and returns to D0, the link\nreturns to L0 before the controller driver even started its transition to\nL1 link state. At this point, the SATA controller did send an PM_ENTER_L1\nDLLP to the PCIe controller and the PCIe controller received it, and the\nPCIe controller did set PMSR PMEL1RX bit.\n\nOnce rcar_pcie_wakeup() is called, if the link is already back in L0 state\nand PMEL1RX bit is set, the controller driver has no way to determine if\nit should perform the link transition to L1 state, or treat the link as if\nit is in L0 state. Currently the driver attempts to perform the transition\nto L1 link state unconditionally, which in this specific case fails with a\nPMSR L1FAEG poll timeout, however the link still works as it is already\nback in L0 state.\n\nReduce this warning verbosity. In case the link is really broken, the\nrcar_pcie_config_access() would fail, otherwise it will succeed and any\nsystem with this controller and ASM1062 can suspend without generating\na backtrace.(CVE-2024-43876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pci: ivtv: Add check for DMA map result\n\nIn case DMA fails, \u0026apos;dma-\u0026gt;SG_length\u0026apos; is 0. This value is later used to\naccess \u0026apos;dma-\u0026gt;SGarray[dma-\u0026gt;SG_length - 1]\u0026apos;, which will cause out of\nbounds access.\n\nAdd check to return early on invalid value. Adjust warnings accordingly.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43877)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_acl_erp: Fix object nesting warning\n\nACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM\n(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can\ncontain more ACLs (i.e., tc filters), but the number of masks in each\nregion (i.e., tc chain) is limited.\n\nIn order to mitigate the effects of the above limitation, the device\nallows filters to share a single mask if their masks only differ in up\nto 8 consecutive bits. For example, dst_ip/25 can be represented using\ndst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the\nnumber of masks being used (and therefore does not support mask\naggregation), but can contain a limited number of filters.\n\nThe driver uses the \u0026quot;objagg\u0026quot; library to perform the mask aggregation by\npassing it objects that consist of the filter\u0026apos;s mask and whether the\nfilter is to be inserted into the A-TCAM or the C-TCAM since filters in\ndifferent TCAMs cannot share a mask.\n\nThe set of created objects is dependent on the insertion order of the\nfilters and is not necessarily optimal. Therefore, the driver will\nperiodically ask the library to compute a more optimal set (\u0026quot;hints\u0026quot;) by\nlooking at all the existing objects.\n\nWhen the library asks the driver whether two objects can be aggregated\nthe driver only compares the provided masks and ignores the A-TCAM /\nC-TCAM indication. This is the right thing to do since the goal is to\nmove as many filters as possible to the A-TCAM. The driver also forbids\ntwo identical masks from being aggregated since this can only happen if\none was intentionally put in the C-TCAM to avoid a conflict in the\nA-TCAM.\n\nThe above can result in the following set of hints:\n\nH1: {mask X, A-TCAM} -\u0026gt; H2: {mask Y, A-TCAM} // X is Y + delta\nH3: {mask Y, C-TCAM} -\u0026gt; H4: {mask Z, A-TCAM} // Y is Z + delta\n\nAfter getting the hints from the library the driver will start migrating\nfilters from one region to another while consulting the computed hints\nand instructing the device to perform a lookup in both regions during\nthe transition.\n\nAssuming a filter with mask X is being migrated into the A-TCAM in the\nnew region, the hints lookup will return H1. Since H2 is the parent of\nH1, the library will try to find the object associated with it and\ncreate it if necessary in which case another hints lookup (recursive)\nwill be performed. This hints lookup for {mask Y, A-TCAM} will either\nreturn H2 or H3 since the driver passes the library an object comparison\nfunction that ignores the A-TCAM / C-TCAM indication.\n\nThis can eventually lead to nested objects which are not supported by\nthe library [1].\n\nFix by removing the object comparison function from both the driver and\nthe library as the driver was the only user. That way the lookup will\nonly return exact matches.\n\nI do not have a reliable reproducer that can reproduce the issue in a\ntimely manner, but before the fix the issue would reproduce in several\nminutes and with the fix it does not reproduce in over an hour.\n\nNote that the current usefulness of the hints is limited because they\ninclude the C-TCAM indication and represent aggregation that cannot\nactually happen. This will be addressed in net-next.\n\n[1]\nWARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0\nModules linked in:\nCPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42\nHardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __objagg_obj_get+0x2bb/0x580\n objagg_obj_get+0xe/0x80\n mlxsw_sp_acl_erp_mask_get+0xb5/0xf0\n mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370(CVE-2024-43880)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: change DMA direction while mapping reinjected packets\n\nFor fragmented packets, ath12k reassembles each fragment as a normal\npacket and then reinjects it into HW ring. In this case, the DMA\ndirection should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,\nan invalid payload may be reinjected into the HW and\nsubsequently delivered to the host.\n\nGiven that arbitrary memory can be allocated to the skb buffer,\nknowledge about the data contained in the reinjected buffer is lacking.\nConsequently, there\u2019s a risk of private information being leaked.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1(CVE-2024-43881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: privcmd: Switch from mutex to spinlock for irqfds\n\nirqfd_wakeup() gets EPOLLHUP, when it is called by\neventfd_release() by way of wake_up_poll(\u0026amp;ctx-\u0026gt;wqh, EPOLLHUP), which\ngets called under spin_lock_irqsave(). We can\u0026apos;t use a mutex here as it\nwill lead to a deadlock.\n\nFix it by switching over to a spin lock.(CVE-2024-44957)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntick/broadcast: Move per CPU pointer access into the atomic section\n\nThe recent fix for making the take over of the broadcast timer more\nreliable retrieves a per CPU pointer in preemptible context.\n\nThis went unnoticed as compilers hoist the access into the non-preemptible\nregion where the pointer is actually used. But of course it\u0026apos;s valid that\nthe compiler keeps it at the place where the code puts it which rightfully\ntriggers:\n\n  BUG: using smp_processor_id() in preemptible [00000000] code:\n       caller is hotplug_cpu__broadcast_tick_pull+0x1c/0xc0\n\nMove it to the actual usage site which is in a non-preemptible region.(CVE-2024-44968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not clear page dirty inside extent_write_locked_range()\n\n[BUG]\nFor subpage + zoned case, the following workload can lead to rsv data\nleak at unmount time:\n\n  # mkfs.btrfs -f -s 4k $dev\n  # mount $dev $mnt\n  # fsstress -w -n 8 -d $mnt -s 1709539240\n  0/0: fiemap - no filename\n  0/1: copyrange read - no filename\n  0/2: write - no filename\n  0/3: rename - no source filename\n  0/4: creat f0 x:0 0 0\n  0/4: creat add id=0,parent=-1\n  0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0\n  0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1\n  0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat()\n  0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0\n  # umount $mnt\n\nThe dmesg includes the following rsv leak detection warning (all call\ntrace skipped):\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  ------------[ cut here ]------------\n  WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): space_info DATA has 268218368 free, is not full\n  BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0\n  BTRFS info (device sda): global_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs]\n  ---[ end trace 0000000000000000 ]---\n  BTRFS info (device sda): space_info METADATA has 267796480 free, is not full\n  BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760\n  BTRFS info (device sda): global_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): trans_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0\n  BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0\n\nAbove $dev is a tcmu-runner emulated zoned HDD, which has a max zone\nappend size of 64K, and the system has 64K page size.\n\n[CAUSE]\nI have added several trace_printk() to show the events (header skipped):\n\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536\n  \u0026gt; btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864\n\nThe above lines show our buffered write has dirtied 3 pages of inode\n259 of root 5:\n\n  704K             768K              832K              896K\n  I           |////I/////////////////I///////////|     I\n              756K                               868K\n\n  |///| is the dirtied range using subpage bitmaps. and \u0026apos;I\u0026apos; is the page\n  boundary.\n\n  Meanwhile all three pages (704K, 768K, 832K) have their PageDirty\n  flag set.\n\n  \u0026gt; btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400\n\nThen direct IO writ\n---truncated---(CVE-2024-44972)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: fix panic caused by partcmd_update\n\nWe find a bug as below:\nBUG: unable to handle page fault for address: 00000003\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 358 Comm: bash Tainted: G        W I        6.6.0-10893-g60d6\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4\nRIP: 0010:partition_sched_domains_locked+0x483/0x600\nCode: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9\nRSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202\nRAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80\nRBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000\nR10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002\nR13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x8c/0xa0\n ? __die_body+0x23/0xa0\n ? __die+0x3a/0x50\n ? page_fault_oops+0x1d2/0x5c0\n ? partition_sched_domains_locked+0x483/0x600\n ? search_module_extables+0x2a/0xb0\n ? search_exception_tables+0x67/0x90\n ? kernelmode_fixup_or_oops+0x144/0x1b0\n ? __bad_area_nosemaphore+0x211/0x360\n ? up_read+0x3b/0x50\n ? bad_area_nosemaphore+0x1a/0x30\n ? exc_page_fault+0x890/0xd90\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? __lock_acquire.constprop.0+0x24f/0x8d0\n ? asm_exc_page_fault+0x26/0x30\n ? partition_sched_domains_locked+0x483/0x600\n ? partition_sched_domains_locked+0xf0/0x600\n rebuild_sched_domains_locked+0x806/0xdc0\n update_partition_sd_lb+0x118/0x130\n cpuset_write_resmask+0xffc/0x1420\n cgroup_file_write+0xb2/0x290\n kernfs_fop_write_iter+0x194/0x290\n new_sync_write+0xeb/0x160\n vfs_write+0x16f/0x1d0\n ksys_write+0x81/0x180\n __x64_sys_write+0x21/0x30\n x64_sys_call+0x2f25/0x4630\n do_syscall_64+0x44/0xb0\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\nRIP: 0033:0x7f44a553c887\n\nIt can be reproduced with cammands:\ncd /sys/fs/cgroup/\nmkdir test\ncd test/\necho +cpuset \u0026gt; ../cgroup.subtree_control\necho root \u0026gt; cpuset.cpus.partition\ncat /sys/fs/cgroup/cpuset.cpus.effective\n0-3\necho 0-3 \u0026gt; cpuset.cpus // taking away all cpus from root\n\nThis issue is caused by the incorrect rebuilding of scheduling domains.\nIn this scenario, test/cpuset.cpus.partition should be an invalid root\nand should not trigger the rebuilding of scheduling domains. When calling\nupdate_parent_effective_cpumask with partcmd_update, if newmask is not\nnull, it should recheck newmask whether there are cpus is available\nfor parect/cs that has tasks.(CVE-2024-44975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mana: Fix RX buf alloc_size alignment and atomic op panic\n\nThe MANA driver\u0026apos;s RX buffer alloc_size is passed into napi_build_skb() to\ncreate SKB. skb_shinfo(skb) is located at the end of skb, and its alignment\nis affected by the alloc_size passed into napi_build_skb(). The size needs\nto be aligned properly for better performance and atomic operations.\nOtherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic\noperations may panic on the skb_shinfo(skb)-\u0026gt;dataref due to alignment fault.\n\nTo fix this bug, add proper alignment to the alloc_size calculation.\n\nSample panic info:\n[  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce\n[  253.300900] Mem abort info:\n[  253.301760]   ESR = 0x0000000096000021\n[  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  253.304268]   SET = 0, FnV = 0\n[  253.305172]   EA = 0, S1PTW = 0\n[  253.306103]   FSC = 0x21: alignment fault\nCall trace:\n __skb_clone+0xfc/0x198\n skb_clone+0x78/0xe0\n raw6_local_deliver+0xfc/0x228\n ip6_protocol_deliver_rcu+0x80/0x500\n ip6_input_finish+0x48/0x80\n ip6_input+0x48/0xc0\n ip6_sublist_rcv_finish+0x50/0x78\n ip6_sublist_rcv+0x1cc/0x2b8\n ipv6_list_rcv+0x100/0x150\n __netif_receive_skb_list_core+0x180/0x220\n netif_receive_skb_list_internal+0x198/0x2a8\n __napi_poll+0x138/0x250\n net_rx_action+0x148/0x330\n handle_softirqs+0x12c/0x3a0(CVE-2024-45001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: s390: fix validity interception issue when gisa is switched off\n\nWe might run into a SIE validity if gisa has been disabled either via using\nkernel parameter \u0026quot;kvm.use_gisa=0\u0026quot; or by setting the related sysfs\nattribute to N (echo N \u0026gt;/sys/module/kvm/parameters/use_gisa).\n\nThe validity is caused by an invalid value in the SIE control block\u0026apos;s\ngisa designation. That happens because we pass the uninitialized gisa\norigin to virt_to_phys() before writing it to the gisa designation.\n\nTo fix this we return 0 in kvm_s390_get_gisa_desc() if the origin is 0.\nkvm_s390_get_gisa_desc() is used to determine which gisa designation to\nset in the SIE control block. A value of 0 in the gisa designation disables\ngisa usage.\n\nThe issue surfaces in the host kernel with the following kernel message as\nsoon a new kvm guest start is attemted.\n\nkvm: unhandled validity intercept 0x1011\nWARNING: CPU: 0 PID: 781237 at arch/s390/kvm/intercept.c:101 kvm_handle_sie_intercept+0x42e/0x4d0 [kvm]\nModules linked in: vhost_net tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT xt_tcpudp nft_compat x_tables nf_nat_tftp nf_conntrack_tftp vfio_pci_core irqbypass vhost_vsock vmw_vsock_virtio_transport_common vsock vhost vhost_iotlb kvm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables sunrpc mlx5_ib ib_uverbs ib_core mlx5_core uvdevice s390_trng eadm_sch vfio_ccw zcrypt_cex4 mdev vfio_iommu_type1 vfio sch_fq_codel drm i2c_core loop drm_panel_orientation_quirks configfs nfnetlink lcs ctcm fsm dm_service_time ghash_s390 prng chacha_s390 libchacha aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dm_mirror dm_region_hash dm_log zfcp scsi_transport_fc scsi_dh_rdac scsi_dh_emc scsi_dh_alua pkey zcrypt dm_multipath rng_core autofs4 [last unloaded: vfio_pci]\nCPU: 0 PID: 781237 Comm: CPU 0/KVM Not tainted 6.10.0-08682-gcad9f11498ea #6\nHardware name: IBM 3931 A01 701 (LPAR)\nKrnl PSW : 0704c00180000000 000003d93deb0122 (kvm_handle_sie_intercept+0x432/0x4d0 [kvm])\n           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\nKrnl GPRS: 000003d900000027 000003d900000023 0000000000000028 000002cd00000000\n           000002d063a00900 00000359c6daf708 00000000000bebb5 0000000000001eff\n           000002cfd82e9000 000002cfd80bc000 0000000000001011 000003d93deda412\n           000003ff8962df98 000003d93de77ce0 000003d93deb011e 00000359c6daf960\nKrnl Code: 000003d93deb0112: c020fffe7259\tlarl\t%r2,000003d93de7e5c4\n           000003d93deb0118: c0e53fa8beac\tbrasl\t%r14,000003d9bd3c7e70\n          #000003d93deb011e: af000000\t\tmc\t0,0\n          \u0026gt;000003d93deb0122: a728ffea\t\tlhi\t%r2,-22\n           000003d93deb0126: a7f4fe24\t\tbrc\t15,000003d93deafd6e\n           000003d93deb012a: 9101f0b0\t\ttm\t176(%r15),1\n           000003d93deb012e: a774fe48\t\tbrc\t7,000003d93deafdbe\n           000003d93deb0132: 40a0f0ae\t\tsth\t%r10,174(%r15)\nCall Trace:\n [\u0026lt;000003d93deb0122\u0026gt;] kvm_handle_sie_intercept+0x432/0x4d0 [kvm]\n([\u0026lt;000003d93deb011e\u0026gt;] kvm_handle_sie_intercept+0x42e/0x4d0 [kvm])\n [\u0026lt;000003d93deacc10\u0026gt;] vcpu_post_run+0x1d0/0x3b0 [kvm]\n [\u0026lt;000003d93deaceda\u0026gt;] __vcpu_run+0xea/0x2d0 [kvm]\n [\u0026lt;000003d93dead9da\u0026gt;] kvm_arch_vcpu_ioctl_run+0x16a/0x430 [kvm]\n [\u0026lt;000003d93de93ee0\u0026gt;] kvm_vcpu_ioctl+0x190/0x7c0 [kvm]\n [\u0026lt;000003d9bd728b4e\u0026gt;] vfs_ioctl+0x2e/0x70\n [\u0026lt;000003d9bd72a092\u0026gt;] __s390x_sys_ioctl+0xc2/0xd0\n [\u0026lt;000003d9be0e9222\u0026gt;] __do_syscall+0x1f2/0x2e0\n [\u0026lt;000003d9be0f9a90\u0026gt;] system_call+0x70/0x98\nLast Breaking-Event-Address:\n [\u0026lt;000003d9bd3c7f58\u0026gt;] __warn_printk+0xe8/0xf0(CVE-2024-45005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nchar: xillybus: Don\u0026apos;t destroy workqueue from work item running on it\n\nTriggered by a kref decrement, destroy_workqueue() may be called from\nwithin a work item for destroying its own workqueue. This illegal\nsituation is averted by adding a module-global workqueue for exclusive\nuse of the offending work item. Other work items continue to be queued\non per-device workqueues to ensure performance.(CVE-2024-45007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/firmware: use dma non-coherent allocator\n\nCurrently, enabling SG_DEBUG in the kernel will cause nouveau to hit a\nBUG() on startup, when the iommu is enabled:\n\nkernel BUG at include/linux/scatterlist.h:187!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30\nHardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019\nRIP: 0010:sg_init_one+0x85/0xa0\nCode: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54\n24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 \u0026lt;0f\u0026gt; 0b 0f 0b\n0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00\nRSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b\nRDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000\nRBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508\nR13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018\nFS:  00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die+0x36/0x90\n ? do_trap+0xdd/0x100\n ? sg_init_one+0x85/0xa0\n ? do_error_trap+0x65/0x80\n ? sg_init_one+0x85/0xa0\n ? exc_invalid_op+0x50/0x70\n ? sg_init_one+0x85/0xa0\n ? asm_exc_invalid_op+0x1a/0x20\n ? sg_init_one+0x85/0xa0\n nvkm_firmware_ctor+0x14a/0x250 [nouveau]\n nvkm_falcon_fw_ctor+0x42/0x70 [nouveau]\n ga102_gsp_booter_ctor+0xb4/0x1a0 [nouveau]\n r535_gsp_oneinit+0xb3/0x15f0 [nouveau]\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? nvkm_udevice_new+0x95/0x140 [nouveau]\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? ktime_get+0x47/0xb0\n\nFix this by using the non-coherent allocator instead, I think there\nmight be a better answer to this, but it involve ripping up some of\nAPIs using sg lists.(CVE-2024-45012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0\n\nThe __vmap_pages_range_noflush() assumes its argument pages** contains\npages with the same page shift.  However, since commit e9c3cda4d86e (\u0026quot;mm,\nvmalloc: fix high order __GFP_NOFAIL allocations\u0026quot;), if gfp_flags includes\n__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation\nfailed for high order, the pages** may contain two different page shifts\n(high order and order-0).  This could lead __vmap_pages_range_noflush() to\nperform incorrect mappings, potentially resulting in memory corruption.\n\nUsers might encounter this as follows (vmap_allow_huge = true, 2M is for\nPMD_SIZE):\n\nkvmalloc(2M, __GFP_NOFAIL|GFP_X)\n    __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP)\n        vm_area_alloc_pages(order=9) ---\u0026gt; order-9 allocation failed and fallback to order-0\n            vmap_pages_range()\n                vmap_pages_range_noflush()\n                    __vmap_pages_range_noflush(page_shift = 21) ----\u0026gt; wrong mapping happens\n\nWe can remove the fallback code because if a high-order allocation fails,\n__vmalloc_node_range_noprof() will retry with order-0.  Therefore, it is\nunnecessary to fallback to order-0 here.  Therefore, fix this by removing\nthe fallback code.(CVE-2024-45022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion\n\nwpa_supplicant 2.11 sends since 1efdba5fdc2c (\u0026quot;Handle PMKSA flush in the\ndriver for SAE/OWE offload cases\u0026quot;) SSID based PMKSA del commands.\nbrcmfmac is not prepared and tries to dereference the NULL bssid and\npmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based\nupdates so copy the SSID.(CVE-2024-46672)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Fix random crash seen while removing driver\n\nThis fixes the random kernel crash seen while removing the driver, when\nrunning the load/unload test over multiple iterations.\n\n1) modprobe btnxpuart\n2) hciconfig hci0 reset\n3) hciconfig (check hci0 interface up with valid BD address)\n4) modprobe -r btnxpuart\nRepeat steps 1 to 4\n\nThe ps_wakeup() call in btnxpuart_close() schedules the psdata-\u0026gt;work(),\nwhich gets scheduled after module is removed, causing a kernel crash.\n\nThis hidden issue got highlighted after enabling Power Save by default\nin 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on\nstartup)\n\nThe new ps_cleanup() deasserts UART break immediately while closing\nserdev device, cancels any scheduled ps_work and destroys the ps_lock\nmutex.\n\n[   85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258\n[   85.884624] Mem abort info:\n[   85.884625]   ESR = 0x0000000086000007\n[   85.884628]   EC = 0x21: IABT (current EL), IL = 32 bits\n[   85.884633]   SET = 0, FnV = 0\n[   85.884636]   EA = 0, S1PTW = 0\n[   85.884638]   FSC = 0x07: level 3 translation fault\n[   85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000\n[   85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000\n[   85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP\n[   85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)]\n[   85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G           O       6.1.36+g937b1be4345a #1\n[   85.936176] Hardware name: FSL i.MX8MM EVK board (DT)\n[   85.936182] Workqueue: events 0xffffd4a61638f380\n[   85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   85.952817] pc : 0xffffd4a61638f258\n[   85.952823] lr : 0xffffd4a61638f258\n[   85.952827] sp : ffff8000084fbd70\n[   85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000\n[   85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305\n[   85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970\n[   85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000\n[   85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090\n[   85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139\n[   85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50\n[   85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8\n[   85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000\n[   85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000\n[   85.977443] Call trace:\n[   85.977446]  0xffffd4a61638f258\n[   85.977451]  0xffffd4a61638f3e8\n[   85.977455]  process_one_work+0x1d4/0x330\n[   85.977464]  worker_thread+0x6c/0x430\n[   85.977471]  kthread+0x108/0x10c\n[   85.977476]  ret_from_fork+0x10/0x20\n[   85.977488] Code: bad PC value\n[   85.977491] ---[ end trace 0000000000000000 ]---\n\nPreset since v6.9.11(CVE-2024-46680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pmic_glink: Fix race during initialization\n\nAs pointed out by Stephen Boyd it is possible that during initialization\nof the pmic_glink child drivers, the protection-domain notifiers fires,\nand the associated work is scheduled, before the client registration\nreturns and as a result the local \u0026quot;client\u0026quot; pointer has been initialized.\n\nThe outcome of this is a NULL pointer dereference as the \u0026quot;client\u0026quot;\npointer is blindly dereferenced.\n\nTimeline provided by Stephen:\n CPU0                               CPU1\n ----                               ----\n ucsi-\u0026gt;client = NULL;\n devm_pmic_glink_register_client()\n  client-\u0026gt;pdr_notify(client-\u0026gt;priv, pg-\u0026gt;client_state)\n   pmic_glink_ucsi_pdr_notify()\n    schedule_work(\u0026amp;ucsi-\u0026gt;register_work)\n    \u0026lt;schedule away\u0026gt;\n                                    pmic_glink_ucsi_register()\n                                     ucsi_register()\n                                      pmic_glink_ucsi_read_version()\n                                       pmic_glink_ucsi_read()\n                                        pmic_glink_ucsi_read()\n                                         pmic_glink_send(ucsi-\u0026gt;client)\n                                         \u0026lt;client is NULL BAD\u0026gt;\n ucsi-\u0026gt;client = client // Too late!\n\nThis code is identical across the altmode, battery manager and usci\nchild drivers.\n\nResolve this by splitting the allocation of the \u0026quot;client\u0026quot; object and the\nregistration thereof into two operations.\n\nThis only happens if the protection domain registry is populated at the\ntime of registration, which by the introduction of commit \u0026apos;1ebcde047c54\n(\u0026quot;soc: qcom: add pd-mapper implementation\u0026quot;)\u0026apos; became much more likely.(CVE-2024-46693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: avoid using null object of framebuffer\n\nInstead of using state-\u0026gt;fb-\u0026gt;obj[0] directly, get object from framebuffer\nby calling drm_gem_fb_get_obj() and return error code when object is\nnull to avoid using null object of framebuffer.\n\n(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)(CVE-2024-46694)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: fix ID 0 endp usage after multiple re-creations\n\n\u0026apos;local_addr_used\u0026apos; and \u0026apos;add_addr_accepted\u0026apos; are decremented for addresses\nnot related to the initial subflow (ID0), because the source and\ndestination addresses of the initial subflows are known from the\nbeginning: they don\u0026apos;t count as \u0026quot;additional local address being used\u0026quot; or\n\u0026quot;ADD_ADDR being accepted\u0026quot;.\n\nIt is then required not to increment them when the entrypoint used by\nthe initial subflow is removed and re-added during a connection. Without\nthis modification, this entrypoint cannot be removed and re-added more\nthan once.(CVE-2024-46711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: Fix double free of \u0026apos;buf\u0026apos; in error path\n\nsmatch warning:\ndrivers/misc/fastrpc.c:1926 fastrpc_req_mmap() error: double free of \u0026apos;buf\u0026apos;\n\nIn fastrpc_req_mmap() error path, the fastrpc buffer is freed in\nfastrpc_req_munmap_impl() if unmap is successful.\n\nBut in the end, there is an unconditional call to fastrpc_buf_free().\nSo the above case triggers the double free of fastrpc buf.(CVE-2024-46741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: void array out of bound when loop tnl_num\n\nWhen query reg inf of SSU, it loops tnl_num times. However, tnl_num comes\nfrom hardware and the length of array is a fixed value. To void array out\nof bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmalloc: ensure vmap_block is initialised before adding to queue\n\nCommit 8c61291fd850 (\u0026quot;mm: fix incorrect vbq reference in\npurge_fragmented_block\u0026quot;) extended the \u0026apos;vmap_block\u0026apos; structure to contain a\n\u0026apos;cpu\u0026apos; field which is set at allocation time to the id of the initialising\nCPU.\n\nWhen a new \u0026apos;vmap_block\u0026apos; is being instantiated by new_vmap_block(), the\npartially initialised structure is added to the local \u0026apos;vmap_block_queue\u0026apos;\nxarray before the \u0026apos;cpu\u0026apos; field has been initialised.  If another CPU is\nconcurrently walking the xarray (e.g.  via vm_unmap_aliases()), then it\nmay perform an out-of-bounds access to the remote queue thanks to an\nuninitialised index.\n\nThis has been observed as UBSAN errors in Android:\n\n | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP\n |\n | Call trace:\n |  purge_fragmented_block+0x204/0x21c\n |  _vm_unmap_aliases+0x170/0x378\n |  vm_unmap_aliases+0x1c/0x28\n |  change_memory_common+0x1dc/0x26c\n |  set_memory_ro+0x18/0x24\n |  module_enable_ro+0x98/0x238\n |  do_init_module+0x1b0/0x310\n\nMove the initialisation of \u0026apos;vb-\u0026gt;cpu\u0026apos; in new_vmap_block() ahead of the\naddition to the xarray.(CVE-2024-46847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/hyperv: fix kexec crash due to VP assist page corruption\n\ncommit 9636be85cc5b (\u0026quot;x86/hyperv: Fix hyperv_pcpu_input_arg handling when\nCPUs go online/offline\u0026quot;) introduces a new cpuhp state for hyperv\ninitialization.\n\ncpuhp_setup_state() returns the state number if state is\nCPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.\nFor the hyperv case, since a new cpuhp state was introduced it would\nreturn 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call\nis conditioned upon \u0026quot;hyperv_init_cpuhp \u0026gt; 0\u0026quot;. This will never be true and\nso hv_cpu_die() won\u0026apos;t be called on all CPUs. This means the VP assist page\nwon\u0026apos;t be reset. When the kexec kernel tries to setup the VP assist page\nagain, the hypervisor corrupts the memory region of the old VP assist page\ncausing a panic in case the kexec kernel is using that memory elsewhere.\nThis was originally fixed in commit dfe94d4086e4 (\u0026quot;x86/hyperv: Fix kexec\npanic/hang issues\u0026quot;).\n\nGet rid of hyperv_init_cpuhp entirely since we are no longer using a\ndynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with\ncpuhp_remove_state().(CVE-2024-46864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfou: fix initialization of grc\n\nThe grc must be initialize first. There can be a condition where if\nfou is NULL, goto out will be executed and grc would be used\nuninitialized.(CVE-2024-46865)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: hisilicon/qm - inject error before stopping queue\n\nThe master ooo cannot be completely closed when the\naccelerator core reports memory error. Therefore, the driver\nneeds to inject the qm error to close the master ooo. Currently,\nthe qm error is injected after stopping queue, memory may be\nreleased immediately after stopping queue, causing the device to\naccess the released memory. Therefore, error is injected to close master\nooo before stopping queue to ensure that the device does not access\nthe released memory.(CVE-2024-47730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled\n\nFix missuse of spin_lock_irq()/spin_unlock_irq() when\nspin_lock_irqsave()/spin_lock_irqrestore() was hold.\n\nThis was discovered through the lock debugging, and the corresponding\nlog is as follows:\n\nraw_local_irq_restore() called with IRQs enabled\nWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40\n...\nCall trace:\n warn_bogus_irq_restore+0x30/0x40\n _raw_spin_unlock_irqrestore+0x84/0xc8\n add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]\n hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]\n hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]\n create_qp+0x138/0x258\n ib_create_qp_kernel+0x50/0xe8\n create_mad_qp+0xa8/0x128\n ib_mad_port_open+0x218/0x448\n ib_mad_init_device+0x70/0x1f8\n add_client_context+0xfc/0x220\n enable_device_and_get+0xd0/0x140\n ib_register_device.part.0+0xf4/0x1c8\n ib_register_device+0x34/0x50\n hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]\n hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]\n hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix a race between socket set up and I/O thread creation\n\nIn rxrpc_open_socket(), it sets up the socket and then sets up the I/O\nthread that will handle it.  This is a problem, however, as there\u0026apos;s a gap\nbetween the two phases in which a packet may come into rxrpc_encap_rcv()\nfrom the UDP packet but we oops when trying to wake the not-yet created I/O\nthread.\n\nAs a quick fix, just make rxrpc_encap_rcv() discard the packet if there\u0026apos;s\nno I/O thread yet.\n\nA better, but more intrusive fix would perhaps be to rearrange things such\nthat the socket creation is done by the I/O thread.(CVE-2024-49864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a sdiv overflow issue\n\nZac Ecob reported a problem where a bpf program may cause kernel crash due\nto the following error:\n  Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI\n\nThe failure is due to the below signed divide:\n  LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808.\nLLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808,\nbut it is impossible since for 64-bit system, the maximum positive\nnumber is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will\ncause a kernel exception. On arm64, the result for LLONG_MIN/-1 is\nLLONG_MIN.\n\nFurther investigation found all the following sdiv/smod cases may trigger\nan exception when bpf program is running on x86_64 platform:\n  - LLONG_MIN/-1 for 64bit operation\n  - INT_MIN/-1 for 32bit operation\n  - LLONG_MIN%-1 for 64bit operation\n  - INT_MIN%-1 for 32bit operation\nwhere -1 can be an immediate or in a register.\n\nOn arm64, there are no exceptions:\n  - LLONG_MIN/-1 = LLONG_MIN\n  - INT_MIN/-1 = INT_MIN\n  - LLONG_MIN%-1 = 0\n  - INT_MIN%-1 = 0\nwhere -1 can be an immediate or in a register.\n\nInsn patching is needed to handle the above cases and the patched codes\nproduced results aligned with above arm64 result. The below are pseudo\ncodes to handle sdiv/smod exceptions including both divisor -1 and divisor 0\nand the divisor is stored in a register.\n\nsdiv:\n      tmp = rX\n      tmp += 1 /* [-1, 0] -\u0026gt; [0, 1]\n      if tmp \u0026gt;(unsigned) 1 goto L2\n      if tmp == 0 goto L1\n      rY = 0\n  L1:\n      rY = -rY;\n      goto L3\n  L2:\n      rY /= rX\n  L3:\n\nsmod:\n      tmp = rX\n      tmp += 1 /* [-1, 0] -\u0026gt; [0, 1]\n      if tmp \u0026gt;(unsigned) 1 goto L1\n      if tmp == 1 (is64 ? goto L2 : goto L3)\n      rY = 0;\n      goto L2\n  L1:\n      rY %= rX\n  L2:\n      goto L4  // only when !is64\n  L3:\n      wY = wY  // only when !is64\n  L4:\n\n  [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/(CVE-2024-49888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()\n\nFor kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is\ndefined as NR_CPUS instead of the number of possible cpus, this\nwill cause the following system panic:\n\nsmpboot: Allowing 4 CPUs, 0 hotplug CPUs\n...\nsetup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1\n...\nBUG: unable to handle page fault for address: ffffffff9911c8c8\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W\n6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6\nRIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0\nRSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082\nCR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? __die+0x23/0x80\n? page_fault_oops+0xa4/0x180\n? exc_page_fault+0x152/0x180\n? asm_exc_page_fault+0x26/0x40\n? rcu_tasks_need_gpcb+0x25d/0x2c0\n? __pfx_rcu_tasks_kthread+0x40/0x40\nrcu_tasks_one_gp+0x69/0x180\nrcu_tasks_kthread+0x94/0xc0\nkthread+0xe8/0x140\n? __pfx_kthread+0x40/0x40\nret_from_fork+0x34/0x80\n? __pfx_kthread+0x40/0x40\nret_from_fork_asm+0x1b/0x80\n\u0026lt;/TASK\u0026gt;\n\nConsidering that there may be holes in the CPU numbers, use the\nmaximum possible cpu number, instead of nr_cpu_ids, for configuring\nenqueue and dequeue limits.\n\n[ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ](CVE-2024-49926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: avoid to add interface to list twice when SER\n\nIf SER L2 occurs during the WoWLAN resume flow, the add interface flow\nis triggered by ieee80211_reconfig(). However, due to\nrtw89_wow_resume() return failure, it will cause the add interface flow\nto be executed again, resulting in a double add list and causing a kernel\npanic. Therefore, we have added a check to prevent double adding of the\nlist.\n\nlist_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:37!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W  O       6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7\nHardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021\nWorkqueue: events_freezable ieee80211_restart_work [mac80211]\nRIP: 0010:__list_add_valid_or_report+0x5e/0xb0\nCode: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 \u0026lt;0f\u0026gt; 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12\nRSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900\nRDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001\nRBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0\nR10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060\nR13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010\nFS:  0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1f/0x70\n ? die+0x3d/0x60\n ? do_trap+0xa4/0x110\n ? __list_add_valid_or_report+0x5e/0xb0\n ? do_error_trap+0x6d/0x90\n ? __list_add_valid_or_report+0x5e/0xb0\n ? handle_invalid_op+0x30/0x40\n ? __list_add_valid_or_report+0x5e/0xb0\n ? exc_invalid_op+0x3c/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_add_valid_or_report+0x5e/0xb0\n rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]\n drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n ? finish_wait+0x3e/0x90\n ? synchronize_rcu_expedited+0x174/0x260\n ? sync_rcu_exp_done_unlocked+0x50/0x50\n ? wake_bit_function+0x40/0x40\n ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n process_scheduled_works+0x1e5/0x480\n worker_thread+0xea/0x1e0\n kthread+0xdb/0x110\n ? move_linked_works+0x90/0x90\n ? kthread_associate_blkcg+0xa0/0xa0\n ret_from_fork+0x3b/0x50\n ? kthread_associate_blkcg+0xa0/0xa0\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\nModules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev\ngsmi: Log Shutdown Reason 0x03\n---[ end trace 0000000000000000 ]---(CVE-2024-49939)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: do not assume bh is held in ppp_channel_bridge_input()\n\nNetworking receive path is usually handled from BH handler.\nHowever, some protocols need to acquire the socket lock, and\npackets might be stored in the socket backlog is the socket was\nowned by a user process.\n\nIn this case, release_sock(), __release_sock(), and sk_backlog_rcv()\nmight call the sk-\u0026gt;sk_backlog_rcv() handler in process context.\n\nsybot caught ppp was not considering this case in\nppp_channel_bridge_input() :\n\nWARNING: inconsistent lock state\n6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted\n--------------------------------\ninconsistent {SOFTIRQ-ON-W} -\u0026gt; {IN-SOFTIRQ-W} usage.\nksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes:\n ffff0000db7f11e0 (\u0026amp;pch-\u0026gt;downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]\n ffff0000db7f11e0 (\u0026amp;pch-\u0026gt;downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]\n ffff0000db7f11e0 (\u0026amp;pch-\u0026gt;downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304\n{SOFTIRQ-ON-W} state was registered at:\n   lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759\n   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n   _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154\n   spin_lock include/linux/spinlock.h:351 [inline]\n   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]\n   ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304\n   pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379\n   sk_backlog_rcv include/net/sock.h:1111 [inline]\n   __release_sock+0x1a8/0x3d8 net/core/sock.c:3004\n   release_sock+0x68/0x1b8 net/core/sock.c:3558\n   pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903\n   sock_sendmsg_nosec net/socket.c:730 [inline]\n   __sock_sendmsg net/socket.c:745 [inline]\n   __sys_sendto+0x374/0x4f4 net/socket.c:2204\n   __do_sys_sendto net/socket.c:2216 [inline]\n   __se_sys_sendto net/socket.c:2212 [inline]\n   __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\n   el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\nirq event stamp: 282914\n hardirqs last  enabled at (282914): [\u0026lt;ffff80008b42e30c\u0026gt;] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]\n hardirqs last  enabled at (282914): [\u0026lt;ffff80008b42e30c\u0026gt;] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194\n hardirqs last disabled at (282913): [\u0026lt;ffff80008b42e13c\u0026gt;] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\n hardirqs last disabled at (282913): [\u0026lt;ffff80008b42e13c\u0026gt;] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162\n softirqs last  enabled at (282904): [\u0026lt;ffff8000801f8e88\u0026gt;] softirq_handle_end kernel/softirq.c:400 [inline]\n softirqs last  enabled at (282904): [\u0026lt;ffff8000801f8e88\u0026gt;] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582\n softirqs last disabled at (282909): [\u0026lt;ffff8000801fbdf8\u0026gt;] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n       CPU0\n       ----\n  lock(\u0026amp;pch-\u0026gt;downl);\n  \u0026lt;Interrupt\u0026gt;\n    lock(\u0026amp;pch-\u0026gt;downl);\n\n *** DEADLOCK ***\n\n1 lock held by ksoftirqd/1/24:\n  #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall trace:\n  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319\n  show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326\n  __dump_sta\n---truncated---(CVE-2024-49946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible crash on mgmt_index_removed\n\nIf mgmt_index_removed is called while there are commands queued on\ncmd_sync it could lead to crashes like the bellow trace:\n\n0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc\n0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]\n0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]\n0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]\n\nSo while handling mgmt_index_removed this attempts to dequeue\ncommands passed as user_data to cmd_sync.(CVE-2024-49951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice\n\nThe km.state is not checked in driver\u0026apos;s delayed work. When\nxfrm_state_check_expire() is called, the state can be reset to\nXFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This\nhappens when xfrm state is deleted, but not freed yet. As\n__xfrm_state_delete() is called again in xfrm timer, the following\ncrash occurs.\n\nTo fix this issue, skip xfrm_state_check_expire() if km.state is not\nXFRM_STATE_VALID.\n\n Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP\n CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]\n RIP: 0010:__xfrm_state_delete+0x3d/0x1b0\n Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 \u0026lt;48\u0026gt; 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48\n RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246\n RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036\n RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980\n RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000\n R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246\n R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400\n FS:  0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u0026lt;IRQ\u0026gt;\n  ? die_addr+0x33/0x90\n  ? exc_general_protection+0x1a2/0x390\n  ? asm_exc_general_protection+0x22/0x30\n  ? __xfrm_state_delete+0x3d/0x1b0\n  ? __xfrm_state_delete+0x2f/0x1b0\n  xfrm_timer_handler+0x174/0x350\n  ? __xfrm_state_delete+0x1b0/0x1b0\n  __hrtimer_run_queues+0x121/0x270\n  hrtimer_run_softirq+0x88/0xd0\n  handle_softirqs+0xcc/0x270\n  do_softirq+0x3c/0x50\n  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\n  __local_bh_enable_ip+0x47/0x50\n  mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]\n  process_one_work+0x137/0x2d0\n  worker_thread+0x28d/0x3a0\n  ? rescuer_thread+0x480/0x480\n  kthread+0xb8/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;(CVE-2024-49953)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpftool: Fix undefined behavior in qsort(NULL, 0, ...)\n\nWhen netfilter has no entry to display, qsort is called with\nqsort(NULL, 0, ...). This results in undefined behavior, as UBSan\nreports:\n\nnet.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null\n\nAlthough the C standard does not explicitly state whether calling qsort\nwith a NULL pointer when the size is 0 constitutes undefined behavior,\nSection 7.1.4 of the C standard (Use of library functions) mentions:\n\n\u0026quot;Each of the following statements applies unless explicitly stated\notherwise in the detailed descriptions that follow: If an argument to a\nfunction has an invalid value (such as a value outside the domain of\nthe function, or a pointer outside the address space of the program, or\na null pointer, or a pointer to non-modifiable storage when the\ncorresponding parameter is not const-qualified) or a type (after\npromotion) not expected by a function with variable number of\narguments, the behavior is undefined.\u0026quot;\n\nTo avoid this, add an early return when nf_link_info is NULL to prevent\ncalling qsort with a NULL pointer.(CVE-2024-49987)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add refcnt to ksmbd_conn struct\n\nWhen sending an oplock break request, opinfo-\u0026gt;conn is used,\nBut freed -\u0026gt;conn can be used on multichannel.\nThis patch add a reference count to the ksmbd_conn struct\nso that it can be freed when it is no longer used.(CVE-2024-49988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: improve shutdown sequence\n\nAlexander Sverdlin presents 2 problems during shutdown with the\nlan9303 driver. One is specific to lan9303 and the other just happens\nto reproduce there.\n\nThe first problem is that lan9303 is unique among DSA drivers in that it\ncalls dev_get_drvdata() at \u0026quot;arbitrary runtime\u0026quot; (not probe, not shutdown,\nnot remove):\n\nphy_state_machine()\n-\u0026gt; ...\n   -\u0026gt; dsa_user_phy_read()\n      -\u0026gt; ds-\u0026gt;ops-\u0026gt;phy_read()\n         -\u0026gt; lan9303_phy_read()\n            -\u0026gt; chip-\u0026gt;ops-\u0026gt;phy_read()\n               -\u0026gt; lan9303_mdio_phy_read()\n                  -\u0026gt; dev_get_drvdata()\n\nBut we never stop the phy_state_machine(), so it may continue to run\nafter dsa_switch_shutdown(). Our common pattern in all DSA drivers is\nto set drvdata to NULL to suppress the remove() method that may come\nafterwards. But in this case it will result in an NPD.\n\nThe second problem is that the way in which we set\ndp-\u0026gt;conduit-\u0026gt;dsa_ptr = NULL; is concurrent with receive packet\nprocessing. dsa_switch_rcv() checks once whether dev-\u0026gt;dsa_ptr is NULL,\nbut afterwards, rather than continuing to use that non-NULL value,\ndev-\u0026gt;dsa_ptr is dereferenced again and again without NULL checks:\ndsa_conduit_find_user() and many other places. In between dereferences,\nthere is no locking to ensure that what was valid once continues to be\nvalid.\n\nBoth problems have the common aspect that closing the conduit interface\nsolves them.\n\nIn the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN\nevent in dsa_user_netdevice_event() which closes user ports as well.\ndsa_port_disable_rt() calls phylink_stop(), which synchronously stops\nthe phylink state machine, and ds-\u0026gt;ops-\u0026gt;phy_read() will thus no longer\ncall into the driver after this point.\n\nIn the second case, dev_close(conduit) should do this, as per\nDocumentation/networking/driver.rst:\n\n| Quiescence\n| ----------\n|\n| After the ndo_stop routine has been called, the hardware must\n| not receive or transmit any data.  All in flight packets must\n| be aborted. If necessary, poll or wait for completion of\n| any reset commands.\n\nSo it should be sufficient to ensure that later, when we zeroize\nconduit-\u0026gt;dsa_ptr, there will be no concurrent dsa_switch_rcv() call\non this conduit.\n\nThe addition of the netif_device_detach() function is to ensure that\nioctls, rtnetlinks and ethtool requests on the user ports no longer\npropagate down to the driver - we\u0026apos;re no longer prepared to handle them.\n\nThe race condition actually did not exist when commit 0650bf52b31f\n(\u0026quot;net: dsa: be compatible with masters which unregister on shutdown\u0026quot;)\nfirst introduced dsa_switch_shutdown(). It was created later, when we\nstopped unregistering the user interfaces from a bad spot, and we just\nreplaced that sequence with a racy zeroization of conduit-\u0026gt;dsa_ptr\n(one which doesn\u0026apos;t ensure that the interfaces aren\u0026apos;t up).(CVE-2024-49998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: fix ppp_async_encode() illegal access\n\nsyzbot reported an issue in ppp_async_encode() [1]\n\nIn this case, pppoe_sendmsg() is called with a zero size.\nThen ppp_async_encode() is called with an empty skb.\n\nBUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]\n BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675\n  ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]\n  ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675\n  ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634\n  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]\n  ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304\n  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379\n  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113\n  __release_sock+0x1da/0x330 net/core/sock.c:3072\n  release_sock+0x6b/0x250 net/core/sock.c:3626\n  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903\n  sock_sendmsg_nosec net/socket.c:729 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:744\n  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n  __do_sys_sendmmsg net/socket.c:2771 [inline]\n  __se_sys_sendmmsg net/socket.c:2768 [inline]\n  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4092 [inline]\n  slab_alloc_node mm/slub.c:4135 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678\n  alloc_skb include/linux/skbuff.h:1322 [inline]\n  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732\n  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867\n  sock_sendmsg_nosec net/socket.c:729 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:744\n  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602\n  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656\n  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742\n  __do_sys_sendmmsg net/socket.c:2771 [inline]\n  __se_sys_sendmmsg net/socket.c:2768 [inline]\n  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768\n  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: Fix multiple init when debugfs is disabled\n\nIf bt_debugfs is not created successfully, which happens if either\nCONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init()\nreturns early and does not set iso_inited to true. This means that a\nsubsequent call to iso_init() will result in duplicate calls to\nproto_register(), bt_sock_register(), etc.\n\nWith CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the\nduplicate call to proto_register() triggers this BUG():\n\n  list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250,\n    next=ffffffffc0b280d0.\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:35!\n  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1\n  RIP: 0010:__list_add_valid_or_report+0x9a/0xa0\n  ...\n    __list_add_valid_or_report+0x9a/0xa0\n    proto_register+0x2b5/0x340\n    iso_init+0x23/0x150 [bluetooth]\n    set_iso_socket_func+0x68/0x1b0 [bluetooth]\n    kmem_cache_free+0x308/0x330\n    hci_sock_sendmsg+0x990/0x9e0 [bluetooth]\n    __sock_sendmsg+0x7b/0x80\n    sock_write_iter+0x9a/0x110\n    do_iter_readv_writev+0x11d/0x220\n    vfs_writev+0x180/0x3e0\n    do_writev+0xca/0x100\n  ...\n\nThis change removes the early return. The check for iso_debugfs being\nNULL was unnecessary, it is always NULL when iso_inited is false.(CVE-2024-50077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error\n\nThe `nouveau_dmem_copy_one` function ensures that the copy push command is\nsent to the device firmware but does not track whether it was executed\nsuccessfully.\n\nIn the case of a copy error (e.g., firmware or hardware failure), the\ncopy push command will be sent via the firmware channel, and\n`nouveau_dmem_copy_one` will likely report success, leading to the\n`migrate_to_ram` function returning a dirty HIGH_USER page to the user.\n\nThis can result in a security vulnerability, as a HIGH_USER page that may\ncontain sensitive or corrupted data could be returned to the user.\n\nTo prevent this vulnerability, we allocate a zero page. Thus, in case of\nan error, a non-dirty (zero) page will be returned to the user.(CVE-2024-50096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix one more kernel-infoleak in algo dumping\n\nDuring fuzz testing, the following issue was discovered:\n\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30\n _copy_to_iter+0x598/0x2a30\n __skb_datagram_iter+0x168/0x1060\n skb_copy_datagram_iter+0x5b/0x220\n netlink_recvmsg+0x362/0x1700\n sock_recvmsg+0x2dc/0x390\n __sys_recvfrom+0x381/0x6d0\n __x64_sys_recvfrom+0x130/0x200\n x64_sys_call+0x32c8/0x3cc0\n do_syscall_64+0xd8/0x1c0\n entry_SYSCALL_64_after_hwframe+0x79/0x81\n\nUninit was stored to memory at:\n copy_to_user_state_extra+0xcc1/0x1e00\n dump_one_state+0x28c/0x5f0\n xfrm_state_walk+0x548/0x11e0\n xfrm_dump_sa+0x1e0/0x840\n netlink_dump+0x943/0x1c40\n __netlink_dump_start+0x746/0xdb0\n xfrm_user_rcv_msg+0x429/0xc00\n netlink_rcv_skb+0x613/0x780\n xfrm_netlink_rcv+0x77/0xc0\n netlink_unicast+0xe90/0x1280\n netlink_sendmsg+0x126d/0x1490\n __sock_sendmsg+0x332/0x3d0\n ____sys_sendmsg+0x863/0xc30\n ___sys_sendmsg+0x285/0x3e0\n __x64_sys_sendmsg+0x2d6/0x560\n x64_sys_call+0x1316/0x3cc0\n do_syscall_64+0xd8/0x1c0\n entry_SYSCALL_64_after_hwframe+0x79/0x81\n\nUninit was created at:\n __kmalloc+0x571/0xd30\n attach_auth+0x106/0x3e0\n xfrm_add_sa+0x2aa0/0x4230\n xfrm_user_rcv_msg+0x832/0xc00\n netlink_rcv_skb+0x613/0x780\n xfrm_netlink_rcv+0x77/0xc0\n netlink_unicast+0xe90/0x1280\n netlink_sendmsg+0x126d/0x1490\n __sock_sendmsg+0x332/0x3d0\n ____sys_sendmsg+0x863/0xc30\n ___sys_sendmsg+0x285/0x3e0\n __x64_sys_sendmsg+0x2d6/0x560\n x64_sys_call+0x1316/0x3cc0\n do_syscall_64+0xd8/0x1c0\n entry_SYSCALL_64_after_hwframe+0x79/0x81\n\nBytes 328-379 of 732 are uninitialized\nMemory access of size 732 starts at ffff88800e18e000\nData copied to user address 00007ff30f48aff0\n\nCPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n\nFixes copying of xfrm algorithms where some random\ndata of the structure fields can end up in userspace.\nPadding in structures may be filled with random (possibly sensitve)\ndata and should never be given directly to user-space.\n\nA similar issue was resolved in the commit\n8222d5910dae (\u0026quot;xfrm: Zero padding when dumping algos and encap\u0026quot;)\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-50110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Enable IRQ if do_ale() triggered in irq-enabled context\n\nUnaligned access exception can be triggered in irq-enabled context such\nas user mode, in this case do_ale() may call get_user() which may cause\nsleep. Then we will get:\n\n BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7\n in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe\n preempt_count: 0, expected: 0\n RCU nest depth: 0, expected: 0\n CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G        W          6.12.0-rc1+ #1723\n Tainted: [W]=WARN\n Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000\n         9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000\n         9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890\n         ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500\n         000000000000020c 000000000000000a 0000000000000000 0000000000000003\n         00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260\n         0000000000000000 0000000000000000 9000000005437650 90000000055d5000\n         0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000\n         0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec\n         00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d\n         ...\n Call Trace:\n [\u0026lt;9000000003803964\u0026gt;] show_stack+0x64/0x1a0\n [\u0026lt;9000000004c57464\u0026gt;] dump_stack_lvl+0x74/0xb0\n [\u0026lt;9000000003861ab4\u0026gt;] __might_resched+0x154/0x1a0\n [\u0026lt;900000000380c96c\u0026gt;] emulate_load_store_insn+0x6c/0xf60\n [\u0026lt;9000000004c58118\u0026gt;] do_ale+0x78/0x180\n [\u0026lt;9000000003801bc8\u0026gt;] handle_ale+0x128/0x1e0\n\nSo enable IRQ if unaligned access exception is triggered in irq-enabled\ncontext to fix it.(CVE-2024-50111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Unregister notifier on eswitch init failure\n\nIt otherwise remains registered and a subsequent attempt at eswitch\nenabling might trigger warnings of the sort:\n\n[  682.589148] ------------[ cut here ]------------\n[  682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered\n[  682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90\n[...snipped]\n[  682.610052] Call Trace:\n[  682.610369]  \u0026lt;TASK\u0026gt;\n[  682.610663]  ? __warn+0x7c/0x110\n[  682.611050]  ? notifier_chain_register+0x3e/0x90\n[  682.611556]  ? report_bug+0x148/0x170\n[  682.611977]  ? handle_bug+0x36/0x70\n[  682.612384]  ? exc_invalid_op+0x13/0x60\n[  682.612817]  ? asm_exc_invalid_op+0x16/0x20\n[  682.613284]  ? notifier_chain_register+0x3e/0x90\n[  682.613789]  atomic_notifier_chain_register+0x25/0x40\n[  682.614322]  mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core]\n[  682.614965]  mlx5_eswitch_enable+0xc9/0x100 [mlx5_core]\n[  682.615551]  mlx5_device_enable_sriov+0x25/0x340 [mlx5_core]\n[  682.616170]  mlx5_core_sriov_configure+0x50/0x170 [mlx5_core]\n[  682.616789]  sriov_numvfs_store+0xb0/0x1b0\n[  682.617248]  kernfs_fop_write_iter+0x117/0x1a0\n[  682.617734]  vfs_write+0x231/0x3f0\n[  682.618138]  ksys_write+0x63/0xe0\n[  682.618536]  do_syscall_64+0x4c/0x100\n[  682.618958]  entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2024-50136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix command bitmask initialization\n\nCommand bitmask have a dedicated bit for MANAGE_PAGES command, this bit\nisn\u0026apos;t Initialize during command bitmask Initialization, only during\nMANAGE_PAGES.\n\nIn addition, mlx5_cmd_trigger_completions() is trying to trigger\ncompletion for MANAGE_PAGES command as well.\n\nHence, in case health error occurred before any MANAGE_PAGES command\nhave been invoke (for example, during mlx5_enable_hca()),\nmlx5_cmd_trigger_completions() will try to trigger completion for\nMANAGE_PAGES command, which will result in null-ptr-deref error.[1]\n\nFix it by Initialize command bitmask correctly.\n\nWhile at it, re-write the code for better understanding.\n\n[1]\nBUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]\nWrite of size 4 at addr 0000000000000214 by task kworker/u96:2/12078\nCPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nWorkqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7e/0xc0\n kasan_report+0xb9/0xf0\n kasan_check_range+0xec/0x190\n mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]\n mlx5_cmd_flush+0x94/0x240 [mlx5_core]\n enter_error_state+0x6c/0xd0 [mlx5_core]\n mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core]\n process_one_work+0x787/0x1490\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? pwq_dec_nr_in_flight+0xda0/0xda0\n ? assign_work+0x168/0x240\n worker_thread+0x586/0xd30\n ? rescuer_thread+0xae0/0xae0\n kthread+0x2df/0x3b0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x70\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;(CVE-2024-50147)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/cs8409: Fix possible NULL dereference\n\nIf snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then\nNULL pointer dereference will occur in the next line.\n\nSince dolphin_fixups function is a hda_fixup function which is not supposed\nto return any errors, add simple check before dereference, ignore the fail.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: qcom: camss: Remove use_count guard in stop_streaming\n\nThe use_count check was introduced so that multiple concurrent Raw Data\nInterfaces RDIs could be driven by different virtual channels VCs on the\nCSIPHY input driving the video pipeline.\n\nThis is an invalid use of use_count though as use_count pertains to the\nnumber of times a video entity has been opened by user-space not the number\nof active streams.\n\nIf use_count and stream-on count don\u0026apos;t agree then stop_streaming() will\nbreak as is currently the case and has become apparent when using CAMSS\nwith libcamera\u0026apos;s released softisp 0.3.\n\nThe use of use_count like this is a bit hacky and right now breaks regular\nusage of CAMSS for a single stream case. Stopping qcam results in the splat\nbelow, and then it cannot be started again and any attempts to do so fails\nwith -EBUSY.\n\n[ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]\n...\n[ 1265.510630] Call trace:\n[ 1265.510636]  __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]\n[ 1265.510648]  vb2_core_streamoff+0x24/0xcc [videobuf2_common]\n[ 1265.510660]  vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2]\n[ 1265.510673]  v4l_streamoff+0x24/0x30 [videodev]\n[ 1265.510707]  __video_do_ioctl+0x190/0x3f4 [videodev]\n[ 1265.510732]  video_usercopy+0x304/0x8c4 [videodev]\n[ 1265.510757]  video_ioctl2+0x18/0x34 [videodev]\n[ 1265.510782]  v4l2_ioctl+0x40/0x60 [videodev]\n...\n[ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state\n[ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state\n[ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st\n\nOne CAMSS specific way to handle multiple VCs on the same RDI might be:\n\n- Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx.\n- The video buffers are already associated with msm_vfeN_rdiX so\n  release video buffers when told to do so by stop_streaming.\n- Only release the power-domains for the CSIPHY, CSID and VFE when\n  their internal refcounts drop.\n\nEither way refusing to release video buffers based on use_count is\nerroneous and should be reverted. The silicon enabling code for selecting\nVCs is perfectly fine. Its a \u0026quot;known missing feature\u0026quot; that concurrent VCs\nwon\u0026apos;t work with CAMSS right now.\n\nInitial testing with this code didn\u0026apos;t show an error but, SoftISP and \u0026quot;real\u0026quot;\nusage with Google Hangouts breaks the upstream code pretty quickly, we need\nto do a partial revert and take another pass at VCs.\n\nThis commit partially reverts commit 89013969e232 (\u0026quot;media: camss: sm8250:\nPipeline starting and stopping for multiple virtual channels\u0026quot;)(CVE-2024-50175)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: k3-r5: Fix error handling when power-up failed\n\nBy simply bailing out, the driver was violating its rule and internal\nassumptions that either both or no rproc should be initialized. E.g.,\nthis could cause the first core to be available but not the second one,\nleading to crashes on its shutdown later on while trying to dereference\nthat second instance.(CVE-2024-50176)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D\n\nFor i.MX7D DRAM related mux clock, the clock source change should ONLY\nbe done done in low level asm code without accessing DRAM, and then\ncalling clk API to sync the HW clock status with clk tree, it should never\ntouch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag\nshould NOT be added, otherwise, DRAM\u0026apos;s clock parent will be disabled when\nDRAM is active, and system will hang.(CVE-2024-50181)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance\n\nDeleting an NPIV instance requires all fabric ndlps to be released before\nan NPIV\u0026apos;s resources can be torn down.  Failure to release fabric ndlps\nbeforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID\nto complete synchronously with usage of wait_queue.(CVE-2024-50183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: amd_sfh: Switch to device-managed dmam_alloc_coherent()\n\nUsing the device-managed version allows to simplify clean-up in probe()\nerror path.\n\nAdditionally, this device-managed ensures proper cleanup, which helps to\nresolve memory errors, page faults, btrfs going read-only, and btrfs\ndisk corruption.(CVE-2024-50189)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfork: do not invoke uffd on fork if error occurs\n\nPatch series \u0026quot;fork: do not expose incomplete mm on fork\u0026quot;.\n\nDuring fork we may place the virtual memory address space into an\ninconsistent state before the fork operation is complete.\n\nIn addition, we may encounter an error during the fork operation that\nindicates that the virtual memory address space is invalidated.\n\nAs a result, we should not be exposing it in any way to external machinery\nthat might interact with the mm or VMAs, machinery that is not designed to\ndeal with incomplete state.\n\nWe specifically update the fork logic to defer khugepaged and ksm to the\nend of the operation and only to be invoked if no error arose, and\ndisallow uffd from observing fork events should an error have occurred.\n\n\nThis patch (of 2):\n\nCurrently on fork we expose the virtual address space of a process to\nuserland unconditionally if uffd is registered in VMAs, regardless of\nwhether an error arose in the fork.\n\nThis is performed in dup_userfaultfd_complete() which is invoked\nunconditionally, and performs two duties - invoking registered handlers\nfor the UFFD_EVENT_FORK event via dup_fctx(), and clearing down\nuserfaultfd_fork_ctx objects established in dup_userfaultfd().\n\nThis is problematic, because the virtual address space may not yet be\ncorrectly initialised if an error arose.\n\nThe change in commit d24062914837 (\u0026quot;fork: use __mt_dup() to duplicate\nmaple tree in dup_mmap()\u0026quot;) makes this more pertinent as we may be in a\nstate where entries in the maple tree are not yet consistent.\n\nWe address this by, on fork error, ensuring that we roll back state that\nwe would otherwise expect to clean up through the event being handled by\nuserland and perform the memory freeing duty otherwise performed by\ndup_userfaultfd_complete().\n\nWe do this by implementing a new function, dup_userfaultfd_fail(), which\nperforms the same loop, only decrementing reference counts.\n\nNote that we perform mmgrab() on the parent and child mm\u0026apos;s, however\nuserfaultfd_ctx_put() will mmdrop() this once the reference count drops to\nzero, so we will avoid memory leaks correctly here.(CVE-2024-50220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Vangogh: Fix kernel memory out of bounds write\n\nKASAN reports that the GPU metrics table allocated in\nvangogh_tables_init() is not large enough for the memset done in\nsmu_cmn_init_soft_gpu_metrics(). Condensed report follows:\n\n[   33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]\n[   33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067\n...\n[   33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G        W          6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544\n[   33.861816] Tainted: [W]=WARN\n[   33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023\n[   33.861822] Call Trace:\n[   33.861826]  \u0026lt;TASK\u0026gt;\n[   33.861829]  dump_stack_lvl+0x66/0x90\n[   33.861838]  print_report+0xce/0x620\n[   33.861853]  kasan_report+0xda/0x110\n[   33.862794]  kasan_check_range+0xfd/0x1a0\n[   33.862799]  __asan_memset+0x23/0x40\n[   33.862803]  smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.863306]  vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.864257]  vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.865682]  amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.866160]  amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]\n[   33.867135]  dev_attr_show+0x43/0xc0\n[   33.867147]  sysfs_kf_seq_show+0x1f1/0x3b0\n[   33.867155]  seq_read_iter+0x3f8/0x1140\n[   33.867173]  vfs_read+0x76c/0xc50\n[   33.867198]  ksys_read+0xfb/0x1d0\n[   33.867214]  do_syscall_64+0x90/0x160\n...\n[   33.867353] Allocated by task 378 on cpu 7 at 22.794876s:\n[   33.867358]  kasan_save_stack+0x33/0x50\n[   33.867364]  kasan_save_track+0x17/0x60\n[   33.867367]  __kasan_kmalloc+0x87/0x90\n[   33.867371]  vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]\n[   33.867835]  smu_sw_init+0xa32/0x1850 [amdgpu]\n[   33.868299]  amdgpu_device_init+0x467b/0x8d90 [amdgpu]\n[   33.868733]  amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]\n[   33.869167]  amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]\n[   33.869608]  local_pci_probe+0xda/0x180\n[   33.869614]  pci_device_probe+0x43f/0x6b0\n\nEmpirically we can confirm that the former allocates 152 bytes for the\ntable, while the latter memsets the 168 large block.\n\nRoot cause appears that when GPU metrics tables for v2_4 parts were added\nit was not considered to enlarge the table to fit.\n\nThe fix in this patch is rather \u0026quot;brute force\u0026quot; and perhaps later should be\ndone in a smarter way, by extracting and consolidating the part version to\nsize logic to a common helper, instead of brute forcing the largest\npossible allocation. Nevertheless, for now this works and fixes the out of\nbounds write.\n\nv2:\n * Drop impossible v3_0 case. (Mario)\n\n(cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)(CVE-2024-50221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()\n\nmodprobe iio-test-gts and rmmod it, then the following memory leak\noccurs:\n\n\tunreferenced object 0xffffff80c810be00 (size 64):\n\t  comm \u0026quot;kunit_try_catch\u0026quot;, pid 1654, jiffies 4294913981\n\t  hex dump (first 32 bytes):\n\t    02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00  ........ ...@...\n\t    80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00  ................\n\t  backtrace (crc a63d875e):\n\t    [\u0026lt;0000000028c1b3c2\u0026gt;] kmemleak_alloc+0x34/0x40\n\t    [\u0026lt;000000001d6ecc87\u0026gt;] __kmalloc_noprof+0x2bc/0x3c0\n\t    [\u0026lt;00000000393795c1\u0026gt;] devm_iio_init_iio_gts+0x4b4/0x16f4\n\t    [\u0026lt;0000000071bb4b09\u0026gt;] 0xffffffdf052a62e0\n\t    [\u0026lt;000000000315bc18\u0026gt;] 0xffffffdf052a6488\n\t    [\u0026lt;00000000f9dc55b5\u0026gt;] kunit_try_run_case+0x13c/0x3ac\n\t    [\u0026lt;00000000175a3fd4\u0026gt;] kunit_generic_run_threadfn_adapter+0x80/0xec\n\t    [\u0026lt;00000000f505065d\u0026gt;] kthread+0x2e8/0x374\n\t    [\u0026lt;00000000bbfb0e5d\u0026gt;] ret_from_fork+0x10/0x20\n\tunreferenced object 0xffffff80cbfe9e70 (size 16):\n\t  comm \u0026quot;kunit_try_catch\u0026quot;, pid 1658, jiffies 4294914015\n\t  hex dump (first 16 bytes):\n\t    10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00  ....@...........\n\t  backtrace (crc 857f0cb4):\n\t    [\u0026lt;0000000028c1b3c2\u0026gt;] kmemleak_alloc+0x34/0x40\n\t    [\u0026lt;000000001d6ecc87\u0026gt;] __kmalloc_noprof+0x2bc/0x3c0\n\t    [\u0026lt;00000000393795c1\u0026gt;] devm_iio_init_iio_gts+0x4b4/0x16f4\n\t    [\u0026lt;0000000071bb4b09\u0026gt;] 0xffffffdf052a62e0\n\t    [\u0026lt;000000007d089d45\u0026gt;] 0xffffffdf052a6864\n\t    [\u0026lt;00000000f9dc55b5\u0026gt;] kunit_try_run_case+0x13c/0x3ac\n\t    [\u0026lt;00000000175a3fd4\u0026gt;] kunit_generic_run_threadfn_adapter+0x80/0xec\n\t    [\u0026lt;00000000f505065d\u0026gt;] kthread+0x2e8/0x374\n\t    [\u0026lt;00000000bbfb0e5d\u0026gt;] ret_from_fork+0x10/0x20\n\t......\n\nIt includes 5*5 times \u0026quot;size 64\u0026quot; memory leaks, which correspond to 5 times\ntest_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int))\nand gts_test_itimes size 5. It also includes 5*1 times \u0026quot;size 16\u0026quot;\nmemory leak, which correspond to one time __test_init_iio_gain_scale()\ncall with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes\nsize 5.\n\nThe reason is that the per_time_gains[i] is not freed which is allocated in\nthe \u0026quot;gts-\u0026gt;num_itime\u0026quot; for loop in iio_gts_build_avail_scale_table().(CVE-2024-50231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()\n\nIn the ad7124_write_raw() function, parameter val can potentially\nbe zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()\nis called within ad7124_set_channel_odr(). The ad7124_write_raw()\nfunction is invoked through the sequence: iio_write_channel_raw() -\u0026gt;\niio_write_channel_attribute() -\u0026gt; iio_channel_write(), with no checks\nin place to ensure val is non-zero.(CVE-2024-50232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom: qmp-usb: fix NULL-deref on runtime suspend\n\nCommit 413db06c05e7 (\u0026quot;phy: qcom-qmp-usb: clean up probe initialisation\u0026quot;)\nremoved most users of the platform device driver data, but mistakenly\nalso removed the initialisation despite the data still being used in the\nruntime PM callbacks.\n\nRestore the driver data initialisation at probe to avoid a NULL-pointer\ndereference on runtime suspend.\n\nApparently no one uses runtime PM, which currently needs to be enabled\nmanually through sysfs, with this driver.(CVE-2024-50240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address\n\nThe device stores IPv6 addresses that are used for encapsulation in\nlinear memory that is managed by the driver.\n\nChanging the remote address of an ip6gre net device never worked\nproperly, but since cited commit the following reproducer [1] would\nresult in a warning [2] and a memory leak [3]. The problem is that the\nnew remote address is never added by the driver to its hash table (and\ntherefore the device) and the old address is never removed from it.\n\nFix by programming the new address when the configuration of the ip6gre\nnet device changes and removing the old one. If the address did not\nchange, then the above would result in increasing the reference count of\nthe address and then decreasing it.\n\n[1]\n # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit\n # ip link set dev bla type ip6gre remote 2001:db8:3::1\n # ip link del dev bla\n # devlink dev reload pci/0000:01:00.0\n\n[2]\nWARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0\nModules linked in:\nCPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nRIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_router_netdevice_event+0x55f/0x1240\n notifier_call_chain+0x5a/0xd0\n call_netdevice_notifiers_info+0x39/0x90\n unregister_netdevice_many_notify+0x63e/0x9d0\n rtnl_dellink+0x16b/0x3a0\n rtnetlink_rcv_msg+0x142/0x3f0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x242/0x390\n netlink_sendmsg+0x1de/0x420\n ____sys_sendmsg+0x2bd/0x320\n ___sys_sendmsg+0x9a/0xe0\n __sys_sendmsg+0x7a/0xd0\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[3]\nunreferenced object 0xffff898081f597a0 (size 32):\n  comm \u0026quot;ip\u0026quot;, pid 1626, jiffies 4294719324\n  hex dump (first 32 bytes):\n    20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01   ...............\n    21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00  !Ia.............\n  backtrace (crc fd9be911):\n    [\u0026lt;00000000df89c55d\u0026gt;] __kmalloc_cache_noprof+0x1da/0x260\n    [\u0026lt;00000000ff2a1ddb\u0026gt;] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340\n    [\u0026lt;000000009ddd445d\u0026gt;] mlxsw_sp_router_netdevice_event+0x47b/0x1240\n    [\u0026lt;00000000743e7757\u0026gt;] notifier_call_chain+0x5a/0xd0\n    [\u0026lt;000000007c7b9e13\u0026gt;] call_netdevice_notifiers_info+0x39/0x90\n    [\u0026lt;000000002509645d\u0026gt;] register_netdevice+0x5f7/0x7a0\n    [\u0026lt;00000000c2e7d2a9\u0026gt;] ip6gre_newlink_common.isra.0+0x65/0x130\n    [\u0026lt;0000000087cd6d8d\u0026gt;] ip6gre_newlink+0x72/0x120\n    [\u0026lt;000000004df7c7cc\u0026gt;] rtnl_newlink+0x471/0xa20\n    [\u0026lt;0000000057ed632a\u0026gt;] rtnetlink_rcv_msg+0x142/0x3f0\n    [\u0026lt;0000000032e0d5b5\u0026gt;] netlink_rcv_skb+0x50/0x100\n    [\u0026lt;00000000908bca63\u0026gt;] netlink_unicast+0x242/0x390\n    [\u0026lt;00000000cdbe1c87\u0026gt;] netlink_sendmsg+0x1de/0x420\n    [\u0026lt;0000000011db153e\u0026gt;] ____sys_sendmsg+0x2bd/0x320\n    [\u0026lt;000000003b6d53eb\u0026gt;] ___sys_sendmsg+0x9a/0xe0\n    [\u0026lt;00000000cae27c62\u0026gt;] __sys_sendmsg+0x7a/0xd0(CVE-2024-50252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()\n\nI got a syzbot report without a repro [1] crashing in nf_send_reset6()\n\nI think the issue is that dev-\u0026gt;hard_header_len is zero, and we attempt\nlater to push an Ethernet header.\n\nUse LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.\n\n[1]\n\nskbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc900045269b0 EFLAGS: 00010282\nRAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800\nRDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000\nRBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc\nR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140\nR13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c\nFS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_push+0xe5/0x100 net/core/skbuff.c:2636\n  eth_header+0x38/0x1f0 net/ethernet/eth.c:83\n  dev_hard_header include/linux/netdevice.h:3208 [inline]\n  nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358\n  nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48\n  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288\n  nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626\n  nf_hook include/linux/netfilter.h:269 [inline]\n  NF_HOOK include/linux/netfilter.h:312 [inline]\n  br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]\n  br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424\n  __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562\n  __netif_receive_skb_one_core net/core/dev.c:5666 [inline]\n  __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781\n  netif_receive_skb_internal net/core/dev.c:5867 [inline]\n  netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926\n  tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550\n  tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007\n  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053\n  new_sync_write fs/read_write.c:590 [inline]\n  vfs_write+0xa6d/0xc90 fs/read_write.c:683\n  ksys_write+0x183/0x2b0 fs/read_write.c:736\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fdbeeb7d1ff\nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48\nRSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff\nRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8\nRBP: 00007fdbeebf12be R08: 0000000\n---truncated---(CVE-2024-50256)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: arc: fix the device for dma_map_single/dma_unmap_single\n\nThe ndev-\u0026gt;dev and pdev-\u0026gt;dev aren\u0026apos;t the same device, use ndev-\u0026gt;dev.parent\nwhich has dma_mask, ndev-\u0026gt;dev.parent is just pdev-\u0026gt;dev.\nOr it would cause the following issue:\n\n[   39.933526] ------------[ cut here ]------------\n[   39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8(CVE-2024-50295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when uninstalling driver\n\nWhen the driver is uninstalled and the VF is disabled concurrently, a\nkernel crash occurs. The reason is that the two actions call function\npci_disable_sriov(). The num_VFs is checked to determine whether to\nrelease the corresponding resources. During the second calling, num_VFs\nis not 0 and the resource release function is called. However, the\ncorresponding resource has been released during the first invoking.\nTherefore, the problem occurs:\n\n[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020\n...\n[15278.131557][T50670] Call trace:\n[15278.134686][T50670]  klist_put+0x28/0x12c\n[15278.138682][T50670]  klist_del+0x14/0x20\n[15278.142592][T50670]  device_del+0xbc/0x3c0\n[15278.146676][T50670]  pci_remove_bus_device+0x84/0x120\n[15278.151714][T50670]  pci_stop_and_remove_bus_device+0x6c/0x80\n[15278.157447][T50670]  pci_iov_remove_virtfn+0xb4/0x12c\n[15278.162485][T50670]  sriov_disable+0x50/0x11c\n[15278.166829][T50670]  pci_disable_sriov+0x24/0x30\n[15278.171433][T50670]  hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]\n[15278.178039][T50670]  hclge_exit+0x28/0xd0 [hclge]\n[15278.182730][T50670]  __se_sys_delete_module.isra.0+0x164/0x230\n[15278.188550][T50670]  __arm64_sys_delete_module+0x1c/0x30\n[15278.193848][T50670]  invoke_syscall+0x50/0x11c\n[15278.198278][T50670]  el0_svc_common.constprop.0+0x158/0x164\n[15278.203837][T50670]  do_el0_svc+0x34/0xcc\n[15278.207834][T50670]  el0_svc+0x20/0x30\n\nFor details, see the following figure.\n\n     rmmod hclge              disable VFs\n----------------------------------------------------\nhclge_exit()            sriov_numvfs_store()\n  ...                     device_lock()\n  pci_disable_sriov()     hns3_pci_sriov_configure()\n                            pci_disable_sriov()\n                              sriov_disable()\n    sriov_disable()             if !num_VFs :\n      if !num_VFs :               return;\n        return;                 sriov_del_vfs()\n      sriov_del_vfs()             ...\n        ...                       klist_put()\n        klist_put()               ...\n        ...                     num_VFs = 0;\n      num_VFs = 0;        device_unlock();\n\nIn this patch, when driver is removing, we get the device_lock()\nto protect num_VFs, just like sriov_numvfs_store().(CVE-2024-50296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()\n\nThe per-netns IP tunnel hash table is protected by the RTNL mutex and\nip_tunnel_find() is only called from the control path where the mutex is\ntaken.\n\nAdd a lockdep expression to hlist_for_each_entry_rcu() in\nip_tunnel_find() in order to validate that the mutex is held and to\nsilence the suspicious RCU usage warning [1].\n\n[1]\nWARNING: suspicious RCU usage\n6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted\n-----------------------------\nnet/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by ip/362:\n #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60\n\nstack backtrace:\nCPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139\nHardware name: Bochs Bochs, BIOS Bochs 01/01/2011\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xba/0x110\n lockdep_rcu_suspicious.cold+0x4f/0xd6\n ip_tunnel_find+0x435/0x4d0\n ip_tunnel_newlink+0x517/0x7a0\n ipgre_newlink+0x14c/0x170\n __rtnl_newlink+0x1173/0x19c0\n rtnl_newlink+0x6c/0xa0\n rtnetlink_rcv_msg+0x3cc/0xf60\n netlink_rcv_skb+0x171/0x450\n netlink_unicast+0x539/0x7f0\n netlink_sendmsg+0x8c1/0xd80\n ____sys_sendmsg+0x8f9/0xc20\n ___sys_sendmsg+0x197/0x1e0\n __sys_sendmsg+0x122/0x1f0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-50304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hdcp: Add encoder check in intel_hdcp_get_capability\n\nSometimes during hotplug scenario or suspend/resume scenario encoder is\nnot always initialized when intel_hdcp_get_capability add\na check to avoid kernel null pointer dereference.(CVE-2024-53051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data\n\nIn case the non-paged data of a SKB carries protocol header and protocol\npayload to be transmitted on a certain platform that the DMA AXI address\nwidth is configured to 40-bit/48-bit, or the size of the non-paged data\nis bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI\naddress width is configured to 32-bit, then this SKB requires at least\ntwo DMA transmit descriptors to serve it.\n\nFor example, three descriptors are allocated to split one DMA buffer\nmapped from one piece of non-paged data:\n    dma_desc[N + 0],\n    dma_desc[N + 1],\n    dma_desc[N + 2].\nThen three elements of tx_q-\u0026gt;tx_skbuff_dma[] will be allocated to hold\nextra information to be reused in stmmac_tx_clean():\n    tx_q-\u0026gt;tx_skbuff_dma[N + 0],\n    tx_q-\u0026gt;tx_skbuff_dma[N + 1],\n    tx_q-\u0026gt;tx_skbuff_dma[N + 2].\nNow we focus on tx_q-\u0026gt;tx_skbuff_dma[entry].buf, which is the DMA buffer\naddress returned by DMA mapping call. stmmac_tx_clean() will try to\nunmap the DMA buffer _ONLY_IF_ tx_q-\u0026gt;tx_skbuff_dma[entry].buf\nis a valid buffer address.\n\nThe expected behavior that saves DMA buffer address of this non-paged\ndata to tx_q-\u0026gt;tx_skbuff_dma[entry].buf is:\n    tx_q-\u0026gt;tx_skbuff_dma[N + 0].buf = NULL;\n    tx_q-\u0026gt;tx_skbuff_dma[N + 1].buf = NULL;\n    tx_q-\u0026gt;tx_skbuff_dma[N + 2].buf = dma_map_single();\nUnfortunately, the current code misbehaves like this:\n    tx_q-\u0026gt;tx_skbuff_dma[N + 0].buf = dma_map_single();\n    tx_q-\u0026gt;tx_skbuff_dma[N + 1].buf = NULL;\n    tx_q-\u0026gt;tx_skbuff_dma[N + 2].buf = NULL;\n\nOn the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the\nDMA engine, tx_q-\u0026gt;tx_skbuff_dma[N + 0].buf is a valid buffer address\nobviously, then the DMA buffer will be unmapped immediately.\nThere may be a rare case that the DMA engine does not finish the\npending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go\nhorribly wrong, DMA is going to access a unmapped/unreferenced memory\nregion, corrupted data will be transmited or iommu fault will be\ntriggered :(\n\nIn contrast, the for-loop that maps SKB fragments behaves perfectly\nas expected, and that is how the driver should do for both non-paged\ndata and paged frags actually.\n\nThis patch corrects DMA map/unmap sequences by fixing the array index\nfor tx_q-\u0026gt;tx_skbuff_dma[entry].buf when assigning DMA buffer address.\n\nTested and verified on DWXGMAC CORE 3.20a(CVE-2024-53058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx\n\nAs the introduction of the support for vsock and unix sockets in sockmap,\ntls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.\nvsock and af_unix sockets have vsock_sock and unix_sock instead of\ninet_connection_sock. For these sockets, tls_get_ctx may return an invalid\npointer and cause page fault in function tls_sw_ctx_rx.\n\nBUG: unable to handle page fault for address: 0000000000040030\nWorkqueue: vsock-loopback vsock_loopback_work\nRIP: 0010:sk_psock_strp_data_ready+0x23/0x60\nCall Trace:\n ? __die+0x81/0xc3\n ? no_context+0x194/0x350\n ? do_page_fault+0x30/0x110\n ? async_page_fault+0x3e/0x50\n ? sk_psock_strp_data_ready+0x23/0x60\n virtio_transport_recv_pkt+0x750/0x800\n ? update_load_avg+0x7e/0x620\n vsock_loopback_work+0xd0/0x100\n process_one_work+0x1a7/0x360\n worker_thread+0x30/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x112/0x130\n ? __kthread_cancel_work+0x40/0x40\n ret_from_fork+0x1f/0x40\n\nv2:\n  - Add IS_ICSK check\nv3:\n  - Update the commits in Fixes(CVE-2024-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: defer partition scanning\n\nWe need to suppress the partition scan from occuring within the\ncontroller\u0026apos;s scan_work context. If a path error occurs here, the IO will\nwait until a path becomes available or all paths are torn down, but that\naction also occurs within scan_work, so it would deadlock. Defer the\npartion scan to a different context that does not block scan_work.(CVE-2024-53093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES\n\nWhile running ISER over SIW, the initiator machine encounters a warning\nfrom skb_splice_from_iter() indicating that a slab page is being used in\nsend_page. To address this, it is better to add a sendpage_ok() check\nwithin the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag\nshould be disabled before entering the network stack.\n\nA similar issue has been discussed for NVMe in this thread:\nhttps://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/\n\n  WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320\n  Call Trace:\n   tcp_sendmsg_locked+0x368/0xe40\n   siw_tx_hdt+0x695/0xa40 [siw]\n   siw_qp_sq_process+0x102/0xb00 [siw]\n   siw_sq_resume+0x39/0x110 [siw]\n   siw_run_sq+0x74/0x160 [siw]\n   kthread+0xd2/0x100\n   ret_from_fork+0x34/0x40\n   ret_from_fork_asm+0x1a/0x30(CVE-2024-53094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: krealloc: Fix MTE false alarm in __do_krealloc\n\nThis patch addresses an issue introduced by commit 1a83a716ec233 (\u0026quot;mm:\nkrealloc: consider spare memory for __GFP_ZERO\u0026quot;) which causes MTE\n(Memory Tagging Extension) to falsely report a slab-out-of-bounds error.\n\nThe problem occurs when zeroing out spare memory in __do_krealloc. The\noriginal code only considered software-based KASAN and did not account\nfor MTE. It does not reset the KASAN tag before calling memset, leading\nto a mismatch between the pointer tag and the memory tag, resulting\nin a false positive.\n\nExample of the error:\n==================================================================\nswapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188\nswapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1\nswapper/0: Pointer tag: [f4], memory tag: [fe]\nswapper/0:\nswapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.\nswapper/0: Hardware name: MT6991(ENG) (DT)\nswapper/0: Call trace:\nswapper/0:  dump_backtrace+0xfc/0x17c\nswapper/0:  show_stack+0x18/0x28\nswapper/0:  dump_stack_lvl+0x40/0xa0\nswapper/0:  print_report+0x1b8/0x71c\nswapper/0:  kasan_report+0xec/0x14c\nswapper/0:  __do_kernel_fault+0x60/0x29c\nswapper/0:  do_bad_area+0x30/0xdc\nswapper/0:  do_tag_check_fault+0x20/0x34\nswapper/0:  do_mem_abort+0x58/0x104\nswapper/0:  el1_abort+0x3c/0x5c\nswapper/0:  el1h_64_sync_handler+0x80/0xcc\nswapper/0:  el1h_64_sync+0x68/0x6c\nswapper/0:  __memset+0x84/0x188\nswapper/0:  btf_populate_kfunc_set+0x280/0x3d8\nswapper/0:  __register_btf_kfunc_id_set+0x43c/0x468\nswapper/0:  register_btf_kfunc_id_set+0x48/0x60\nswapper/0:  register_nf_nat_bpf+0x1c/0x40\nswapper/0:  nf_nat_init+0xc0/0x128\nswapper/0:  do_one_initcall+0x184/0x464\nswapper/0:  do_initcall_level+0xdc/0x1b0\nswapper/0:  do_initcalls+0x70/0xc0\nswapper/0:  do_basic_setup+0x1c/0x28\nswapper/0:  kernel_init_freeable+0x144/0x1b8\nswapper/0:  kernel_init+0x20/0x1a8\nswapper/0:  ret_from_fork+0x10/0x20\n==================================================================(CVE-2024-53097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: tcp: avoid race between queue_lock lock and destroy\n\nCommit 76d54bf20cdc (\u0026quot;nvme-tcp: don\u0026apos;t access released socket during\nerror recovery\u0026quot;) added a mutex_lock() call for the queue-\u0026gt;queue_lock\nin nvme_tcp_get_address(). However, the mutex_lock() races with\nmutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.\n\nDEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\nWARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220\nModules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]\nCPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:__mutex_lock+0xcf0/0x1220\nCode: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd \u0026lt;0f\u0026gt; 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1\nRSP: 0018:ffff88811305f760 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001\nRBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341\nR10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058\nFS:  00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn.cold+0x5b/0x1af\n ? __mutex_lock+0xcf0/0x1220\n ? report_bug+0x1ec/0x390\n ? handle_bug+0x3c/0x80\n ? exc_invalid_op+0x13/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? __mutex_lock+0xcf0/0x1220\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0xd6a/0x59e0\n ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]\n ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]\n nvme_sysfs_show_address+0x81/0xc0 [nvme_core]\n dev_attr_show+0x42/0x80\n ? __asan_memset+0x1f/0x40\n sysfs_kf_seq_show+0x1f0/0x370\n seq_read_iter+0x2cb/0x1130\n ? rw_verify_area+0x3b1/0x590\n ? __mutex_lock+0x433/0x1220\n vfs_read+0x6a6/0xa20\n ? lockdep_hardirqs_on+0x78/0x100\n ? __pfx_vfs_read+0x10/0x10\n ksys_read+0xf7/0x1d0\n ? __pfx_ksys_read+0x10/0x10\n ? __x64_sys_openat+0x105/0x1d0\n do_syscall_64+0x93/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? __pfx_ksys_read+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on_prepare+0x16d/0x400\n ? do_syscall_64+0x9f/0x180\n ? lockdep_hardirqs_on+0x78/0x100\n ? do_syscall_64+0x9f/0x180\n ? do_syscall_64+0x9f/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f9713f55cfa\nCode: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4\n---truncated---(CVE-2024-53100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: fix buffer overrun in ima_eventdigest_init_common\n\nFunction ima_eventdigest_init() calls ima_eventdigest_init_common()\nwith HASH_ALGO__LAST which is then used to access the array\nhash_digest_size[] leading to buffer overrun. Have a conditional\nstatement to handle this.(CVE-2024-53106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnommu: pass NULL argument to vma_iter_prealloc()\n\nWhen deleting a vma entry from a maple tree, it has to pass NULL to\nvma_iter_prealloc() in order to calculate internal state of the tree, but\nit passed a wrong argument.  As a result, nommu kernels crashed upon\naccessing a vma iterator, such as acct_collect() reading the size of vma\nentries after do_munmap().\n\nThis commit fixes this issue by passing a right argument to the\npreallocation call.(CVE-2024-53109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix NULL pointer dereference in alloc_pages_bulk_noprof\n\nWe triggered a NULL pointer dereference for ac.preferred_zoneref-\u0026gt;zone in\nalloc_pages_bulk_noprof() when the task is migrated between cpusets.\n\nWhen cpuset is enabled, in prepare_alloc_pages(), ac-\u0026gt;nodemask may be\n\u0026amp;current-\u0026gt;mems_allowed.  when first_zones_zonelist() is called to find\npreferred_zoneref, the ac-\u0026gt;nodemask may be modified concurrently if the\ntask is migrated between different cpusets.  Assuming we have 2 NUMA Node,\nwhen traversing Node1 in ac-\u0026gt;zonelist, the nodemask is 2, and when\ntraversing Node2 in ac-\u0026gt;zonelist, the nodemask is 1.  As a result, the\nac-\u0026gt;preferred_zoneref points to NULL zone.\n\nIn alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a\nallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading\nto NULL pointer dereference.\n\n__alloc_pages_noprof() fixes this issue by checking NULL pointer in commit\nea57485af8f4 (\u0026quot;mm, page_alloc: fix check for NULL preferred_zone\u0026quot;) and\ncommit df76cee6bbeb (\u0026quot;mm, page_alloc: remove redundant checks from alloc\nfastpath\u0026quot;).\n\nTo fix it, check NULL pointer for preferred_zoneref-\u0026gt;zone.(CVE-2024-53113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio/vsock: Fix accept_queue memory leak\n\nAs the final stages of socket destruction may be delayed, it is possible\nthat virtio_transport_recv_listen() will be called after the accept_queue\nhas been flushed, but before the SOCK_DONE flag has been set. As a result,\nsockets enqueued after the flush would remain unremoved, leading to a\nmemory leak.\n\nvsock_release\n  __vsock_release\n    lock\n    virtio_transport_release\n      virtio_transport_close\n        schedule_delayed_work(close_work)\n    sk_shutdown = SHUTDOWN_MASK\n(!) flush accept_queue\n    release\n                                        virtio_transport_recv_pkt\n                                          vsock_find_bound_socket\n                                          lock\n                                          if flag(SOCK_DONE) return\n                                          virtio_transport_recv_listen\n                                            child = vsock_create_connected\n                                      (!)   vsock_enqueue_accept(child)\n                                          release\nclose_work\n  lock\n  virtio_transport_do_close\n    set_flag(SOCK_DONE)\n    virtio_transport_remove_sock\n      vsock_remove_sock\n        vsock_remove_bound\n  release\n\nIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() during\nsocket destruction.\n\nunreferenced object 0xffff888109e3f800 (size 2040):\n  comm \u0026quot;kworker/5:2\u0026quot;, pid 371, jiffies 4294940105\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............\n  backtrace (crc 9e5f4e84):\n    [\u0026lt;ffffffff81418ff1\u0026gt;] kmem_cache_alloc_noprof+0x2c1/0x360\n    [\u0026lt;ffffffff81d27aa0\u0026gt;] sk_prot_alloc+0x30/0x120\n    [\u0026lt;ffffffff81d2b54c\u0026gt;] sk_alloc+0x2c/0x4b0\n    [\u0026lt;ffffffff81fe049a\u0026gt;] __vsock_create.constprop.0+0x2a/0x310\n    [\u0026lt;ffffffff81fe6d6c\u0026gt;] virtio_transport_recv_pkt+0x4dc/0x9a0\n    [\u0026lt;ffffffff81fe745d\u0026gt;] vsock_loopback_work+0xfd/0x140\n    [\u0026lt;ffffffff810fc6ac\u0026gt;] process_one_work+0x20c/0x570\n    [\u0026lt;ffffffff810fce3f\u0026gt;] worker_thread+0x1bf/0x3a0\n    [\u0026lt;ffffffff811070dd\u0026gt;] kthread+0xdd/0x110\n    [\u0026lt;ffffffff81044fdd\u0026gt;] ret_from_fork+0x2d/0x50\n    [\u0026lt;ffffffff8100785a\u0026gt;] ret_from_fork_asm+0x1a/0x30(CVE-2024-53119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: CT: Fix null-ptr-deref in add rule err flow\n\nIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()\ncallback returns error, zone_rule-\u0026gt;attr is used uninitiated. Fix it to\nuse attr which has the needed pointer value.\n\nKernel log:\n BUG: kernel NULL pointer dereference, address: 0000000000000110\n RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]\n\u2026\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die+0x20/0x70\n  ? page_fault_oops+0x150/0x3e0\n  ? exc_page_fault+0x74/0x140\n  ? asm_exc_page_fault+0x22/0x30\n  ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]\n  ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core]\n  mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core]\n  ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]\n  nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]\n  flow_offload_work_handler+0x142/0x320 [nf_flow_table]\n  ? finish_task_switch.isra.0+0x15b/0x2b0\n  process_one_work+0x16c/0x320\n  worker_thread+0x28c/0x3a0\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0xb8/0xf0\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x2d/0x50\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;(CVE-2024-53120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fs, lock FTE when checking if active\n\nThe referenced commits introduced a two-step process for deleting FTEs:\n\n- Lock the FTE, delete it from hardware, set the hardware deletion function\n  to NULL and unlock the FTE.\n- Lock the parent flow group, delete the software copy of the FTE, and\n  remove it from the xarray.\n\nHowever, this approach encounters a race condition if a rule with the same\nmatch value is added simultaneously. In this scenario, fs_core may set the\nhardware deletion function to NULL prematurely, causing a panic during\nsubsequent rule deletions.\n\nTo prevent this, ensure the active flag of the FTE is checked under a lock,\nwhich will prevent the fs_core layer from attaching a new steering rule to\nan FTE that is in the process of deletion.\n\n[  438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func\n[  438.968205] ------------[ cut here ]------------\n[  438.968654] refcount_t: decrement hit 0; leaking memory.\n[  438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110\n[  438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]\n[  438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8\n[  438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[  438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110\n[  438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff \u0026lt;0f\u0026gt; 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90\n[  438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286\n[  438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000\n[  438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0\n[  438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0\n[  438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0\n[  438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0\n[  438.980607] FS:  00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000\n[  438.983984] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0\n[  438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  438.986507] Call Trace:\n[  438.986799]  \u0026lt;TASK\u0026gt;\n[  438.987070]  ? __warn+0x7d/0x110\n[  438.987426]  ? refcount_warn_saturate+0xfb/0x110\n[  438.987877]  ? report_bug+0x17d/0x190\n[  438.988261]  ? prb_read_valid+0x17/0x20\n[  438.988659]  ? handle_bug+0x53/0x90\n[  438.989054]  ? exc_invalid_op+0x14/0x70\n[  438.989458]  ? asm_exc_invalid_op+0x16/0x20\n[  438.989883]  ? refcount_warn_saturate+0xfb/0x110\n[  438.990348]  mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]\n[  438.990932]  __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]\n[  438.991519]  ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]\n[  438.992054]  ? xas_load+0x9/0xb0\n[  438.992407]  mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]\n[  438.993037]  mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]\n[  438.993623]  mlx5e_flow_put+0x29/0x60 [mlx5_core]\n[  438.994161]  mlx5e_delete_flower+0x261/0x390 [mlx5_core]\n[  438.994728]  tc_setup_cb_destroy+0xb9/0x190\n[  438.995150]  fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n[  438.995650]  fl_change+0x11a4/0x13c0 [cls_flower]\n[  438.996105]  tc_new_tfilter+0x347/0xbc0\n[  438.996503]  ? __\n---truncated---(CVE-2024-53121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: cope racing subflow creation in mptcp_rcv_space_adjust\n\nAdditional active subflows - i.e. created by the in kernel path\nmanager - are included into the subflow list before starting the\n3whs.\n\nA racing recvmsg() spooling data received on an already established\nsubflow would unconditionally call tcp_cleanup_rbuf() on all the\ncurrent subflows, potentially hitting a divide by zero error on\nthe newly created ones.\n\nExplicitly check that the subflow is in a suitable state before\ninvoking tcp_cleanup_rbuf().(CVE-2024-53122)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: error out earlier on disconnect\n\nEric reported a division by zero splat in the MPTCP protocol:\n\nOops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted\n6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0\nHardware name: Google Google Compute Engine/Google Compute Engine,\nBIOS Google 09/13/2024\nRIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163\nCode: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8\n0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 \u0026lt;f7\u0026gt; 7c\n24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89\nRSP: 0018:ffffc900041f7930 EFLAGS: 00010293\nRAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b\nRDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004\nRBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67\nR10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80\nR13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000\nFS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493\nmptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]\nmptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289\ninet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885\nsock_recvmsg_nosec net/socket.c:1051 [inline]\nsock_recvmsg+0x1b2/0x250 net/socket.c:1073\n__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265\n__do_sys_recvfrom net/socket.c:2283 [inline]\n__se_sys_recvfrom net/socket.c:2279 [inline]\n__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7feb5d857559\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48\n89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d\n01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d\nRAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559\nRDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000\nR10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c\nR13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef\n\nand provided a nice reproducer.\n\nThe root cause is the current bad handling of racing disconnect.\nAfter the blamed commit below, sk_wait_data() can return (with\nerror) with the underlying socket disconnected and a zero rcv_mss.\n\nCatch the error and return without performing any additional\noperations on the current socket.(CVE-2024-53123)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix data-races around sk-\u0026gt;sk_forward_alloc\n\nSyzkaller reported this warning:\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0\n Modules linked in:\n CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:inet_sock_destruct+0x1c5/0x1e0\n Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 \u0026lt;0f\u0026gt; 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00\n RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206\n RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007\n RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00\n RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007\n R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00\n R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78\n FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __warn+0x88/0x130\n  ? inet_sock_destruct+0x1c5/0x1e0\n  ? report_bug+0x18e/0x1a0\n  ? handle_bug+0x53/0x90\n  ? exc_invalid_op+0x18/0x70\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? inet_sock_destruct+0x1c5/0x1e0\n  __sk_destruct+0x2a/0x200\n  rcu_do_batch+0x1aa/0x530\n  ? rcu_do_batch+0x13b/0x530\n  rcu_core+0x159/0x2f0\n  handle_softirqs+0xd3/0x2b0\n  ? __pfx_smpboot_thread_fn+0x10/0x10\n  run_ksoftirqd+0x25/0x30\n  smpboot_thread_fn+0xdd/0x1d0\n  kthread+0xd3/0x100\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x34/0x50\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1a/0x30\n  \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n\nIts possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()\nconcurrently when sk-\u0026gt;sk_state == TCP_LISTEN with sk-\u0026gt;sk_lock unlocked,\nwhich triggers a data-race around sk-\u0026gt;sk_forward_alloc:\ntcp_v6_rcv\n    tcp_v6_do_rcv\n        skb_clone_and_charge_r\n            sk_rmem_schedule\n                __sk_mem_schedule\n                    sk_forward_alloc_add()\n            skb_set_owner_r\n                sk_mem_charge\n                    sk_forward_alloc_add()\n        __kfree_skb\n            skb_release_all\n                skb_release_head_state\n                    sock_rfree\n                        sk_mem_uncharge\n                            sk_forward_alloc_add()\n                            sk_mem_reclaim\n                                // set local var reclaimable\n                                __sk_mem_reclaim\n                                    sk_forward_alloc_add()\n\nIn this syzkaller testcase, two threads call\ntcp_v6_do_rcv() with skb-\u0026gt;truesize=768, the sk_forward_alloc changes like\nthis:\n (cpu 1)             | (cpu 2)             | sk_forward_alloc\n ...                 | ...                 | 0\n __sk_mem_schedule() |                     | +4096 = 4096\n                     | __sk_mem_schedule() | +4096 = 8192\n sk_mem_charge()     |                     | -768  = 7424\n                     | sk_mem_charge()     | -768  = 6656\n ...                 |    ...              |\n sk_mem_uncharge()   |                     | +768  = 7424\n reclaimable=7424    |                     |\n                     | sk_mem_uncharge()   | +768  = 8192\n                     | reclaimable=8192    |\n __sk_mem_reclaim()  |                     | -4096 = 4096\n                     | __sk_mem_reclaim()  | -8192 = -4096 != 0\n\nThe skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when\nsk-\u0026gt;sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().\nFix the same issue in dccp_v6_do_rcv().(CVE-2024-53124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN\n\nHide KVM\u0026apos;s pt_mode module param behind CONFIG_BROKEN, i.e. disable support\nfor virtualizing Intel PT via guest/host mode unless BROKEN=y.  There are\nmyriad bugs in the implementation, some of which are fatal to the guest,\nand others which put the stability and health of the host at risk.\n\nFor guest fatalities, the most glaring issue is that KVM fails to ensure\ntracing is disabled, and *stays* disabled prior to VM-Enter, which is\nnecessary as hardware disallows loading (the guest\u0026apos;s) RTIT_CTL if tracing\nis enabled (enforced via a VMX consistency check).  Per the SDM:\n\n  If the logical processor is operating with Intel PT enabled (if\n  IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \u0026quot;load\n  IA32_RTIT_CTL\u0026quot; VM-entry control must be 0.\n\nOn the host side, KVM doesn\u0026apos;t validate the guest CPUID configuration\nprovided by userspace, and even worse, uses the guest configuration to\ndecide what MSRs to save/load at VM-Enter and VM-Exit.  E.g. configuring\nguest CPUID to enumerate more address ranges than are supported in hardware\nwill result in KVM trying to passthrough, save, and load non-existent MSRs,\nwhich generates a variety of WARNs, ToPA ERRORs in the host, a potential\ndeadlock, etc.(CVE-2024-53135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: kTLS, Fix incorrect page refcounting\n\nThe kTLS tx handling code is using a mix of get_page() and\npage_ref_inc() APIs to increment the page reference. But on the release\npath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.\n\nThis is an issue when using pages from large folios: the get_page()\nreferences are stored on the folio page while the page_ref_inc()\nreferences are stored directly in the given page. On release the folio\npage will be dereferenced too many times.\n\nThis was found while doing kTLS testing with sendfile() + ZC when the\nserved file was read from NFS on a kernel with NFS large folios support\n(commit 49b29a573da8 (\u0026quot;nfs: add support for large folios\u0026quot;)).(CVE-2024-53138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix possible UAF in sctp_v6_available()\n\nA lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints\nthat sctp_v6_available() is calling dev_get_by_index_rcu()\nand ipv6_chk_addr() without holding rcu.\n\n[1]\n =============================\n WARNING: suspicious RCU usage\n 6.12.0-rc5-virtme #1216 Tainted: G        W\n -----------------------------\n net/core/dev.c:876 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by sctp_hello/31495:\n #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp\n\nstack backtrace:\n CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G        W          6.12.0-rc5-virtme #1216\n Tainted: [W]=WARN\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:123)\n lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)\n dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))\n sctp_v6_available (net/sctp/ipv6.c:701) sctp\n sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp\n sctp_bind (net/sctp/socket.c:320) sctp\n inet6_bind_sk (net/ipv6/af_inet6.c:465)\n ? security_socket_bind (security/security.c:4581 (discriminator 1))\n __sys_bind (net/socket.c:1848 net/socket.c:1869)\n ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)\n ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))\n __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))\n do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n RIP: 0033:0x7f59b934a1e7\n Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48\nAll code\n========\n   0:\t44 00 00             \tadd    %r8b,(%rax)\n   3:\t48 8b 15 39 8c 0c 00 \tmov    0xc8c39(%rip),%rdx        # 0xc8c43\n   a:\tf7 d8                \tneg    %eax\n   c:\t64 89 02             \tmov    %eax,%fs:(%rdx)\n   f:\tb8 ff ff ff ff       \tmov    $0xffffffff,%eax\n  14:\teb bd                \tjmp    0xffffffffffffffd3\n  16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1)\n  1d:\t00 00 00\n  20:\t0f 1f 00             \tnopl   (%rax)\n  23:\tb8 31 00 00 00       \tmov    $0x31,%eax\n  28:\t0f 05                \tsyscall\n  2a:*\t48 3d 01 f0 ff ff    \tcmp    $0xfffffffffffff001,%rax\t\t\u0026lt;-- trapping instruction\n  30:\t73 01                \tjae    0x33\n  32:\tc3                   \tret\n  33:\t48 8b 0d 09 8c 0c 00 \tmov    0xc8c09(%rip),%rcx        # 0xc8c43\n  3a:\tf7 d8                \tneg    %eax\n  3c:\t64 89 01             \tmov    %eax,%fs:(%rcx)\n  3f:\t48                   \trex.W\n\nCode starting with the faulting instruction\n===========================================\n   0:\t48 3d 01 f0 ff ff    \tcmp    $0xfffffffffffff001,%rax\n   6:\t73 01                \tjae    0x9\n   8:\tc3                   \tret\n   9:\t48 8b 0d 09 8c 0c 00 \tmov    0xc8c09(%rip),%rcx        # 0xc8c19\n  10:\tf7 d8                \tneg    %eax\n  12:\t64 89 01             \tmov    %eax,%fs:(%rcx)\n  15:\t48                   \trex.W\n RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031\n RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7\n RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005\n RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000\n R10: 00007f59b9253298 R11: 000000000000\n---truncated---(CVE-2024-53139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: terminate outstanding dump on socket close\n\nNetlink supports iterative dumping of data. It provides the families\nthe following ops:\n - start - (optional) kicks off the dumping process\n - dump  - actual dump helper, keeps getting called until it returns 0\n - done  - (optional) pairs with .start, can be used for cleanup\nThe whole process is asynchronous and the repeated calls to .dump\ndon\u0026apos;t actually happen in a tight loop, but rather are triggered\nin response to recvmsg() on the socket.\n\nThis gives the user full control over the dump, but also means that\nthe user can close the socket without getting to the end of the dump.\nTo make sure .start is always paired with .done we check if there\nis an ongoing dump before freeing the socket, and if so call .done.\n\nThe complication is that sockets can get freed from BH and .done\nis allowed to sleep. So we use a workqueue to defer the call, when\nneeded.\n\nUnfortunately this does not work correctly. What we defer is not\nthe cleanup but rather releasing a reference on the socket.\nWe have no guarantee that we own the last reference, if someone\nelse holds the socket they may release it in BH and we\u0026apos;re back\nto square one.\n\nThe whole dance, however, appears to be unnecessary. Only the user\ncan interact with dumps, so we can clean up when socket is closed.\nAnd close always happens in process context. Some async code may\nstill access the socket after close, queue notification skbs to it etc.\nbut no dumps can start, end or otherwise make progress.\n\nDelete the workqueue and flush the dump state directly from the release\nhandler. Note that further cleanup is possible in -next, for instance\nwe now always call .done before releasing the main module reference,\nso dump doesn\u0026apos;t have to take a reference of its own.(CVE-2024-53140)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE\n\nThis aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4\n(\u0026quot;Bluetooth: Always request for user confirmation for Just Works\u0026quot;)\nalways request user confirmation with confirm_hint set since the\nlikes of bluetoothd have dedicated policy around JUST_WORKS method\n(e.g. main.conf:JustWorksRepairing).\n\nCVE: CVE-2024-8805(CVE-2024-53144)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: Fix potential integer overflow during physmem setup\n\nThis issue happens when the real map size is greater than LONG_MAX,\nwhich can be easily triggered on UML/i386.(CVE-2024-53145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix bfqq uaf in bfq_limit_depth()\n\nSet new allocated bfqq to bic or remove freed bfqq from bic are both\nprotected by bfqd-\u0026gt;lock, however bfq_limit_depth() is deferencing bfqq\nfrom bic without the lock, this can lead to UAF if the io_context is\nshared by multiple tasks.\n\nFor example, test bfq with io_uring can trigger following UAF in v6.6:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x47/0x80\n print_address_description.constprop.0+0x66/0x300\n print_report+0x3e/0x70\n kasan_report+0xb4/0xf0\n bfqq_group+0x15/0x50\n bfqq_request_over_limit+0x130/0x9a0\n bfq_limit_depth+0x1b5/0x480\n __blk_mq_alloc_requests+0x2b5/0xa00\n blk_mq_get_new_requests+0x11d/0x1d0\n blk_mq_submit_bio+0x286/0xb00\n submit_bio_noacct_nocheck+0x331/0x400\n __block_write_full_folio+0x3d0/0x640\n writepage_cb+0x3b/0xc0\n write_cache_pages+0x254/0x6c0\n write_cache_pages+0x254/0x6c0\n do_writepages+0x192/0x310\n filemap_fdatawrite_wbc+0x95/0xc0\n __filemap_fdatawrite_range+0x99/0xd0\n filemap_write_and_wait_range.part.0+0x4d/0xa0\n blkdev_read_iter+0xef/0x1e0\n io_read+0x1b6/0x8a0\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 808602:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n __kasan_slab_alloc+0x83/0x90\n kmem_cache_alloc_node+0x1b1/0x6d0\n bfq_get_queue+0x138/0xfa0\n bfq_get_bfqq_handle_split+0xe3/0x2c0\n bfq_init_rq+0x196/0xbb0\n bfq_insert_request.isra.0+0xb5/0x480\n bfq_insert_requests+0x156/0x180\n blk_mq_insert_request+0x15d/0x440\n blk_mq_submit_bio+0x8a4/0xb00\n submit_bio_noacct_nocheck+0x331/0x400\n __blkdev_direct_IO_async+0x2dd/0x330\n blkdev_write_iter+0x39a/0x450\n io_write+0x22a/0x840\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x1b/0x30\n\nFreed by task 808589:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n kasan_save_free_info+0x27/0x40\n __kasan_slab_free+0x126/0x1b0\n kmem_cache_free+0x10c/0x750\n bfq_put_queue+0x2dd/0x770\n __bfq_insert_request.isra.0+0x155/0x7a0\n bfq_insert_request.isra.0+0x122/0x480\n bfq_insert_requests+0x156/0x180\n blk_mq_dispatch_plug_list+0x528/0x7e0\n blk_mq_flush_plug_list.part.0+0xe5/0x590\n __blk_flush_plug+0x3b/0x90\n blk_finish_plug+0x40/0x60\n do_writepages+0x19d/0x310\n filemap_fdatawrite_wbc+0x95/0xc0\n __filemap_fdatawrite_range+0x99/0xd0\n filemap_write_and_wait_range.part.0+0x4d/0xa0\n blkdev_read_iter+0xef/0x1e0\n io_read+0x1b6/0x8a0\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x1b/0x30\n\nFix the problem by protecting bic_to_bfqq() with bfqd-\u0026gt;lock.(CVE-2024-53166)\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\ntcp: Fix use-after-free of nreq in reqsk_timer_handler().\n\nThe cited commit replaced inet_csk_reqsk_queue_drop_and_put() with\n__inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler().\n\nThen, oreq should be passed to reqsk_put() instead of req; otherwise\nuse-after-free of nreq could happen when reqsk is migrated but the\nretry attempt failed (e.g. due to timeout).\n\nLet\u0026apos;s pass oreq to reqsk_put().(CVE-2024-53206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible deadlocks\n\nThis fixes possible deadlocks like the following caused by\nhci_cmd_sync_dequeue causing the destroy function to run:\n\n INFO: task kworker/u19:0:143 blocked for more than 120 seconds.\n       Tainted: G        W  O        6.8.0-2024-03-19-intel-next-iLS-24ww14 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u19:0   state:D stack:0     pid:143   tgid:143   ppid:2      flags:0x00004000\n Workqueue: hci0 hci_cmd_sync_work [bluetooth]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  __schedule+0x374/0xaf0\n  schedule+0x3c/0xf0\n  schedule_preempt_disabled+0x1c/0x30\n  __mutex_lock.constprop.0+0x3ef/0x7a0\n  __mutex_lock_slowpath+0x13/0x20\n  mutex_lock+0x3c/0x50\n  mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]\n  ? kfree+0x211/0x2a0\n  hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]\n  ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]\n  cmd_complete_rsp+0x26/0x80 [bluetooth]\n  mgmt_pending_foreach+0x4d/0x70 [bluetooth]\n  __mgmt_power_off+0x8d/0x180 [bluetooth]\n  ? _raw_spin_unlock_irq+0x23/0x40\n  hci_dev_close_sync+0x445/0x5b0 [bluetooth]\n  hci_set_powered_sync+0x149/0x250 [bluetooth]\n  set_powered_sync+0x24/0x60 [bluetooth]\n  hci_cmd_sync_work+0x90/0x150 [bluetooth]\n  process_one_work+0x13e/0x300\n  worker_thread+0x2f7/0x420\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0x107/0x140\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x3d/0x60\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork_asm+0x1b/0x30\n  \u0026lt;/TASK\u0026gt;(CVE-2024-53207)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix receive ring space parameters when XDP is active\n\nThe MTU setting at the time an XDP multi-buffer is attached\ndetermines whether the aggregation ring will be used and the\nrx_skb_func handler.  This is done in bnxt_set_rx_skb_mode().\n\nIf the MTU is later changed, the aggregation ring setting may need\nto be changed and it may become out-of-sync with the settings\ninitially done in bnxt_set_rx_skb_mode().  This may result in\nrandom memory corruption and crashes as the HW may DMA data larger\nthan the allocated buffer size, such as:\n\nBUG: kernel NULL pointer dereference, address: 00000000000003c0\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S         OE      6.1.0-226bf9805506 #1\nHardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021\nRIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]\nCode: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 \u0026lt;0f\u0026gt; b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f\nRSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202\nRAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff\nRDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380\nRBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf\nR10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980\nR13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990\nFS:  0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en]\n\nTo address the issue, we now call bnxt_set_rx_skb_mode() within\nbnxt_change_mtu() to properly set the AGG rings configuration and\nupdate rx_skb_func based on the new MTU value.\nAdditionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning of\nbnxt_set_rx_skb_mode() to make sure it gets set or cleared based on\nthe current MTU.(CVE-2024-53209)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs\n\nBase clocks are the first in being probed and are real dependencies of the\nrest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,\nRT305x and RT3883 \u0026apos;xtal\u0026apos; must be defined first since in any other case,\nwhen fixed clocks are probed they are delayed until \u0026apos;xtal\u0026apos; is probed so the\nfollowing warning appears:\n\n WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0\n Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000\n 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000\n 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000\n 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009\n 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000\n ...\n Call Trace:\n [\u0026lt;800065d0\u0026gt;] show_stack+0x64/0xf4\n [\u0026lt;804bca14\u0026gt;] dump_stack_lvl+0x38/0x60\n [\u0026lt;800218ac\u0026gt;] __warn+0x94/0xe4\n [\u0026lt;8002195c\u0026gt;] warn_slowpath_fmt+0x60/0x94\n [\u0026lt;80259ff8\u0026gt;] rt3883_bus_recalc_rate+0x98/0x138\n [\u0026lt;80254530\u0026gt;] __clk_register+0x568/0x688\n [\u0026lt;80254838\u0026gt;] of_clk_hw_register+0x18/0x2c\n [\u0026lt;8070b910\u0026gt;] rt2880_clk_of_clk_init_driver+0x18c/0x594\n [\u0026lt;8070b628\u0026gt;] of_clk_init+0x1c0/0x23c\n [\u0026lt;806fc448\u0026gt;] plat_time_init+0x58/0x18c\n [\u0026lt;806fdaf0\u0026gt;] time_init+0x10/0x6c\n [\u0026lt;806f9bc4\u0026gt;] start_kernel+0x458/0x67c\n\n ---[ end trace 0000000000000000 ]---\n\nWhen this driver was mainlined we could not find any active users of old\nralink SoCs so we cannot perform any real tests for them. Now, one user\nof a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and\nreported some issues in openWRT:\n- https://github.com/openwrt/openwrt/issues/16054\n\nThus, define a \u0026apos;rt2880_xtal_recalc_rate()\u0026apos; just returning the expected\nfrequency 40Mhz and use it along the old ralink SoCs to have a correct\nboot trace with no warnings and a working clock plan from the beggining.(CVE-2024-53223)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix use-after-free in device_for_each_child()\n\nSyzbot has reported the following KASAN splat:\n\nBUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0\nRead of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980\n\nCPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x100/0x190\n ? device_for_each_child+0x18f/0x1a0\n print_report+0x13a/0x4cb\n ? __virt_addr_valid+0x5e/0x590\n ? __phys_addr+0xc6/0x150\n ? device_for_each_child+0x18f/0x1a0\n kasan_report+0xda/0x110\n ? device_for_each_child+0x18f/0x1a0\n ? __pfx_dev_memalloc_noio+0x10/0x10\n device_for_each_child+0x18f/0x1a0\n ? __pfx_device_for_each_child+0x10/0x10\n pm_runtime_set_memalloc_noio+0xf2/0x180\n netdev_unregister_kobject+0x1ed/0x270\n unregister_netdevice_many_notify+0x123c/0x1d80\n ? __mutex_trylock_common+0xde/0x250\n ? __pfx_unregister_netdevice_many_notify+0x10/0x10\n ? trace_contention_end+0xe6/0x140\n ? __mutex_lock+0x4e7/0x8f0\n ? __pfx_lock_acquire.part.0+0x10/0x10\n ? rcu_is_watching+0x12/0xc0\n ? unregister_netdev+0x12/0x30\n unregister_netdevice_queue+0x30d/0x3f0\n ? __pfx_unregister_netdevice_queue+0x10/0x10\n ? __pfx_down_write+0x10/0x10\n unregister_netdev+0x1c/0x30\n bnep_session+0x1fb3/0x2ab0\n ? __pfx_bnep_session+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? __pfx_woken_wake_function+0x10/0x10\n ? __kthread_parkme+0x132/0x200\n ? __pfx_bnep_session+0x10/0x10\n ? kthread+0x13a/0x370\n ? __pfx_bnep_session+0x10/0x10\n kthread+0x2b7/0x370\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x48/0x80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 4974:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_noprof+0x1d1/0x440\n hci_alloc_dev_priv+0x1d/0x2820\n __vhci_create_device+0xef/0x7d0\n vhci_write+0x2c7/0x480\n vfs_write+0x6a0/0xfc0\n ksys_write+0x12f/0x260\n do_syscall_64+0xc7/0x250\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 4979:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x4f/0x70\n kfree+0x141/0x490\n hci_release_dev+0x4d9/0x600\n bt_host_release+0x6a/0xb0\n device_release+0xa4/0x240\n kobject_put+0x1ec/0x5a0\n put_device+0x1f/0x30\n vhci_release+0x81/0xf0\n __fput+0x3f6/0xb30\n task_work_run+0x151/0x250\n do_exit+0xa79/0x2c30\n do_group_exit+0xd5/0x2a0\n get_signal+0x1fcd/0x2210\n arch_do_signal_or_restart+0x93/0x780\n syscall_exit_to_user_mode+0x140/0x290\n do_syscall_64+0xd4/0x250\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn \u0026apos;hci_conn_del_sysfs()\u0026apos;, \u0026apos;device_unregister()\u0026apos; may be called when\nan underlying (kobject) reference counter is greater than 1. This\nmeans that reparenting (happened when the device is actually freed)\nis delayed and, during that delay, parent controller device (hciX)\nmay be deleted. Since the latter may create a dangling pointer to\nfreed parent, avoid that scenario by reparenting to NULL explicitly.(CVE-2024-53237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/ivpu: Fix WARN in ivpu_ipc_send_receive_internal()\n\nMove pm_runtime_set_active() to ivpu_pm_init() so when\nivpu_ipc_send_receive_internal() is executed before ivpu_pm_enable()\nit already has correct runtime state, even if last resume was\nnot successful..(CVE-2024-54193)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer\n\nThe AD7923 was updated to support devices with 8 channels, but the size\nof tx_buf and ring_xfer was not increased accordingly, leading to a\npotential buffer overflow in ad7923_update_scan_mode().(CVE-2024-56557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nad7780: fix division by zero in ad7780_write_raw()\n\nIn the ad7780_write_raw() , val2 can be zero, which might lead to a\ndivision by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()\nis based on iio_info\u0026apos;s write_raw. While val is explicitly declared that\ncan be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)\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\nscsi: hisi_sas: Add cond_resched() for no forced preemption model\n\nFor no forced preemption model kernel, in the scenario where the\nexpander is connected to 12 high performance SAS SSDs, the following\ncall trace may occur:\n\n[  214.409199][  C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]\n[  214.568533][  C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)\n[  214.575224][  C240] pc : fput_many+0x8c/0xdc\n[  214.579480][  C240] lr : fput+0x1c/0xf0\n[  214.583302][  C240] sp : ffff80002de2b900\n[  214.587298][  C240] x29: ffff80002de2b900 x28: ffff1082aa412000\n[  214.593291][  C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000\n[  214.599284][  C240] x25: ffff1062bbac5c40 x24: 0000000000001000\n[  214.605277][  C240] x23: 000000000000000a x22: 0000000000000001\n[  214.611270][  C240] x21: 0000000000001000 x20: 0000000000000000\n[  214.617262][  C240] x19: ffff3062a41ae580 x18: 0000000000010000\n[  214.623255][  C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0\n[  214.629248][  C240] x15: ffffffffffffffff x14: 0000000003ffffff\n[  214.635241][  C240] x13: 000000000000ffff x12: 000000000000029c\n[  214.641234][  C240] x11: 0000000000000006 x10: ffff80003a9f7fd0\n[  214.647226][  C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001\n[  214.653219][  C240] x7 : 0000000000000002 x6 : 0000000000000080\n[  214.659212][  C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554\n[  214.665205][  C240] x3 : 0000000000000002 x2 : 0000000000000020\n[  214.671198][  C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8\n[  214.677191][  C240] Call trace:\n[  214.680320][  C240]  fput_many+0x8c/0xdc\n[  214.684230][  C240]  fput+0x1c/0xf0\n[  214.687707][  C240]  aio_complete_rw+0xd8/0x1fc\n[  214.692225][  C240]  blkdev_bio_end_io+0x98/0x140\n[  214.696917][  C240]  bio_endio+0x160/0x1bc\n[  214.701001][  C240]  blk_update_request+0x1c8/0x3bc\n[  214.705867][  C240]  scsi_end_request+0x3c/0x1f0\n[  214.710471][  C240]  scsi_io_completion+0x7c/0x1a0\n[  214.715249][  C240]  scsi_finish_command+0x104/0x140\n[  214.720200][  C240]  scsi_softirq_done+0x90/0x180\n[  214.724892][  C240]  blk_mq_complete_request+0x5c/0x70\n[  214.730016][  C240]  scsi_mq_done+0x48/0xac\n[  214.734194][  C240]  sas_scsi_task_done+0xbc/0x16c [libsas]\n[  214.739758][  C240]  slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]\n[  214.746185][  C240]  cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]\n[  214.752179][  C240]  irq_thread_fn+0x34/0xa4\n[  214.756435][  C240]  irq_thread+0xc4/0x130\n[  214.760520][  C240]  kthread+0x108/0x13c\n[  214.764430][  C240]  ret_from_fork+0x10/0x18\n\nThis is because in the hisi_sas driver, both the hardware interrupt\nhandler and the interrupt thread are executed on the same CPU. In the\nperformance test scenario, function irq_wait_for_interrupt() will always\nreturn 0 if lots of interrupts occurs and the CPU will be continuously\nconsumed. As a result, the CPU cannot run the watchdog thread. When the\nwatchdog time exceeds the specified time, call trace occurs.\n\nTo fix it, add cond_resched() to execute the watchdog thread.(CVE-2024-56589)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix not checking skb length on hci_acldata_packet\n\nThis fixes not checking if skb really contains an ACL header otherwise\nthe code may attempt to access some uninitilized/invalid memory past the\nvalid skb-\u0026gt;data.(CVE-2024-56590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix OOB map writes when deleting elements\n\nJordy says:\n\n\u0026quot;\nIn the xsk_map_delete_elem function an unsigned integer\n(map-\u0026gt;max_entries) is compared with a user-controlled signed integer\n(k). Due to implicit type conversion, a large unsigned value for\nmap-\u0026gt;max_entries can bypass the intended bounds check:\n\n\tif (k \u0026gt;= map-\u0026gt;max_entries)\n\t\treturn -EINVAL;\n\nThis allows k to hold a negative value (between -2147483648 and -2),\nwhich is then used as an array index in m-\u0026gt;xsk_map[k], which results\nin an out-of-bounds access.\n\n\tspin_lock_bh(\u0026amp;m-\u0026gt;lock);\n\tmap_entry = \u0026amp;m-\u0026gt;xsk_map[k]; // Out-of-bounds map_entry\n\told_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write\n\tif (old_xs)\n\t\txsk_map_sock_delete(old_xs, map_entry);\n\tspin_unlock_bh(\u0026amp;m-\u0026gt;lock);\n\nThe xchg operation can then be used to cause an out-of-bounds write.\nMoreover, the invalid map_entry passed to xsk_map_sock_delete can lead\nto further memory corruption.\n\u0026quot;\n\nIt indeed results in following splat:\n\n[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108\n[76612.904330] #PF: supervisor write access in kernel mode\n[76612.909639] #PF: error_code(0x0002) - not-present page\n[76612.914855] PGD 0 P4D 0\n[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP\n[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470\n[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60\n[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff \u0026lt;48\u0026gt; 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31\n[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246\n[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000\n[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000\n[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007\n[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8\n[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0\n[76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000\n[76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0\n[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[76613.041086] PKRU: 55555554\n[76613.043842] Call Trace:\n[76613.046331]  \u0026lt;TASK\u0026gt;\n[76613.048468]  ? __die+0x20/0x60\n[76613.051581]  ? page_fault_oops+0x15a/0x450\n[76613.055747]  ? search_extable+0x22/0x30\n[76613.059649]  ? search_bpf_extables+0x5f/0x80\n[76613.063988]  ? exc_page_fault+0xa9/0x140\n[76613.067975]  ? asm_exc_page_fault+0x22/0x30\n[76613.072229]  ? xsk_map_delete_elem+0x2d/0x60\n[76613.076573]  ? xsk_map_delete_elem+0x23/0x60\n[76613.080914]  __sys_bpf+0x19b7/0x23c0\n[76613.084555]  __x64_sys_bpf+0x1a/0x20\n[76613.088194]  do_syscall_64+0x37/0xb0\n[76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[76613.096962] RIP: 0033:0x7f80b6d1e88d\n[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48\n[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141\n[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d\n[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003\n[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000\n[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8\n[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00\n---truncated---(CVE-2024-56614)\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\nnet/smc: fix LGR and link use-after-free issue\n\nWe encountered a LGR/link use-after-free issue, which manifested as\nthe LGR/link refcnt reaching 0 early and entering the clear process,\nmaking resource access unsafe.\n\n refcount_t: addition on 0; use-after-free.\n WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140\n Workqueue: events smc_lgr_terminate_work [smc]\n Call trace:\n  refcount_warn_saturate+0x9c/0x140\n  __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]\n  smc_lgr_terminate_work+0x28/0x30 [smc]\n  process_one_work+0x1b8/0x420\n  worker_thread+0x158/0x510\n  kthread+0x114/0x118\n\nor\n\n refcount_t: underflow; use-after-free.\n WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140\n Workqueue: smc_hs_wq smc_listen_work [smc]\n Call trace:\n  refcount_warn_saturate+0xf0/0x140\n  smcr_link_put+0x1cc/0x1d8 [smc]\n  smc_conn_free+0x110/0x1b0 [smc]\n  smc_conn_abort+0x50/0x60 [smc]\n  smc_listen_find_device+0x75c/0x790 [smc]\n  smc_listen_work+0x368/0x8a0 [smc]\n  process_one_work+0x1b8/0x420\n  worker_thread+0x158/0x510\n  kthread+0x114/0x118\n\nIt is caused by repeated release of LGR/link refcnt. One suspect is that\nsmc_conn_free() is called repeatedly because some smc_conn_free() from\nserver listening path are not protected by sock lock.\n\ne.g.\n\nCalls under socklock        | smc_listen_work\n-------------------------------------------------------\nlock_sock(sk)               | smc_conn_abort\nsmc_conn_free               | \\- smc_conn_free\n\\- smcr_link_put            |    \\- smcr_link_put (duplicated)\nrelease_sock(sk)\n\nSo here add sock lock protection in smc_listen_work() path, making it\nexclusive with other connection operations.(CVE-2024-56640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: initialize close_work early to avoid warning\n\nWe encountered a warning that close_work was canceled before\ninitialization.\n\n  WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0\n  Workqueue: events smc_lgr_terminate_work [smc]\n  RIP: 0010:__flush_work+0x19e/0x1b0\n  Call Trace:\n   ? __wake_up_common+0x7a/0x190\n   ? work_busy+0x80/0x80\n   __cancel_work_timer+0xe3/0x160\n   smc_close_cancel_work+0x1a/0x70 [smc]\n   smc_close_active_abort+0x207/0x360 [smc]\n   __smc_lgr_terminate.part.38+0xc8/0x180 [smc]\n   process_one_work+0x19e/0x340\n   worker_thread+0x30/0x370\n   ? process_one_work+0x340/0x340\n   kthread+0x117/0x130\n   ? __kthread_cancel_work+0x50/0x50\n   ret_from_fork+0x22/0x30\n\nThis is because when smc_close_cancel_work is triggered, e.g. the RDMA\ndriver is rmmod and the LGR is terminated, the conn-\u0026gt;close_work is\nflushed before initialization, resulting in WARN_ON(!work-\u0026gt;func).\n\n__smc_lgr_terminate             | smc_connect_{rdma|ism}\n-------------------------------------------------------------\n                                | smc_conn_create\n\t\t\t\t| \\- smc_lgr_register_conn\nfor conn in lgr-\u0026gt;conns_all      |\n\\- smc_conn_kill                |\n   \\- smc_close_active_abort    |\n      \\- smc_close_cancel_work  |\n         \\- cancel_work_sync    |\n            \\- __flush_work     |\n\t         (close_work)   |\n\t                        | smc_close_init\n\t                        | \\- INIT_WORK(\u0026amp;close_work)\n\nSo fix this by initializing close_work before establishing the\nconnection.(CVE-2024-56641)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btmtk: avoid UAF in btmtk_process_coredump\n\nhci_devcd_append may lead to the release of the skb, so it cannot be\naccessed once it is called.\n\n==================================================================\nBUG: KASAN: slab-use-after-free in btmtk_process_coredump+0x2a7/0x2d0 [btmtk]\nRead of size 4 at addr ffff888033cfabb0 by task kworker/0:3/82\n\nCPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G     U             6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c\nHardware name: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 05/07/2024\nWorkqueue: events btusb_rx_work [btusb]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xfd/0x150\n print_report+0x131/0x780\n kasan_report+0x177/0x1c0\n btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01]\n btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec]\n btusb_rx_work+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec]\n worker_thread+0xe44/0x2cc0\n kthread+0x2ff/0x3a0\n ret_from_fork+0x51/0x80\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 82:\n stack_trace_save+0xdc/0x190\n kasan_set_track+0x4e/0x80\n __kasan_slab_alloc+0x4e/0x60\n kmem_cache_alloc+0x19f/0x360\n skb_clone+0x132/0xf70\n btusb_recv_acl_mtk+0x104/0x1a0 [btusb]\n btusb_rx_work+0x9e/0xe0 [btusb]\n worker_thread+0xe44/0x2cc0\n kthread+0x2ff/0x3a0\n ret_from_fork+0x51/0x80\n ret_from_fork_asm+0x1b/0x30\n\nFreed by task 1733:\n stack_trace_save+0xdc/0x190\n kasan_set_track+0x4e/0x80\n kasan_save_free_info+0x28/0xb0\n ____kasan_slab_free+0xfd/0x170\n kmem_cache_free+0x183/0x3f0\n hci_devcd_rx+0x91a/0x2060 [bluetooth]\n worker_thread+0xe44/0x2cc0\n kthread+0x2ff/0x3a0\n ret_from_fork+0x51/0x80\n ret_from_fork_asm+0x1b/0x30\n\nThe buggy address belongs to the object at ffff888033cfab40\n which belongs to the cache skbuff_head_cache of size 232\nThe buggy address is located 112 bytes inside of\n freed 232-byte region [ffff888033cfab40, ffff888033cfac28)\n\nThe buggy address belongs to the physical page:\npage:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33cfa\nhead:00000000a174ba93 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0\nanon flags: 0x4000000000000840(slab|head|zone=1)\npage_type: 0xffffffff()\nraw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001\nraw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc\n ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb\n\u0026gt;ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                     ^\n ffff888033cfac00: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc\n ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\n\nCheck if we need to call hci_devcd_complete before calling\nhci_devcd_append. That requires that we check data-\u0026gt;cd_info.cnt \u0026gt;=\nMTK_COREDUMP_NUM instead of data-\u0026gt;cd_info.cnt \u0026gt; MTK_COREDUMP_NUM, as we\nincrement data-\u0026gt;cd_info.cnt only once the call to hci_devcd_append\nsucceeds.(CVE-2024-56653)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()\n\nDuring early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,\nsince pageblock_order is still zero and it gets initialized\nlater during initmem_init() e.g.\nsetup_arch() -\u0026gt; initmem_init() -\u0026gt; sparse_init() -\u0026gt; set_pageblock_order()\n\nOne such use case where this causes issue is -\nearly_setup() -\u0026gt; early_init_devtree() -\u0026gt; fadump_reserve_mem() -\u0026gt; fadump_cma_init()\n\nThis causes CMA memory alignment check to be bypassed in\ncma_init_reserved_mem(). Then later cma_activate_area() can hit\na VM_BUG_ON_PAGE(pfn \u0026amp; ((1 \u0026lt;\u0026lt; order) - 1)) if the reserved memory\narea was not pageblock_order aligned.\n\nFix it by moving the fadump_cma_init() after initmem_init(),\nwhere other such cma reservations also gets called.\n\n\u0026lt;stack trace\u0026gt;\n==============\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010\nflags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA\nraw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000\nraw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: VM_BUG_ON_PAGE(pfn \u0026amp; ((1 \u0026lt;\u0026lt; order) - 1))\n------------[ cut here ]------------\nkernel BUG at mm/page_alloc.c:778!\n\nCall Trace:\n__free_one_page+0x57c/0x7b0 (unreliable)\nfree_pcppages_bulk+0x1a8/0x2c8\nfree_unref_page_commit+0x3d4/0x4e4\nfree_unref_page+0x458/0x6d0\ninit_cma_reserved_pageblock+0x114/0x198\ncma_init_reserved_areas+0x270/0x3e0\ndo_one_initcall+0x80/0x2f8\nkernel_init_freeable+0x33c/0x530\nkernel_init+0x34/0x26c\nret_from_kernel_user_thread+0x14/0x1c(CVE-2024-56677)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: musb: Fix hardware lockup on first Rx endpoint request\n\nThere is a possibility that a request\u0026apos;s callback could be invoked from\nusb_ep_queue() (call trace below, supplemented with missing calls):\n\nreq-\u0026gt;complete from usb_gadget_giveback_request\n\t(drivers/usb/gadget/udc/core.c:999)\nusb_gadget_giveback_request from musb_g_giveback\n\t(drivers/usb/musb/musb_gadget.c:147)\nmusb_g_giveback from rxstate\n\t(drivers/usb/musb/musb_gadget.c:784)\nrxstate from musb_ep_restart\n\t(drivers/usb/musb/musb_gadget.c:1169)\nmusb_ep_restart from musb_ep_restart_resume_work\n\t(drivers/usb/musb/musb_gadget.c:1176)\nmusb_ep_restart_resume_work from musb_queue_resume_work\n\t(drivers/usb/musb/musb_core.c:2279)\nmusb_queue_resume_work from musb_gadget_queue\n\t(drivers/usb/musb/musb_gadget.c:1241)\nmusb_gadget_queue from usb_ep_queue\n\t(drivers/usb/gadget/udc/core.c:300)\n\nAccording to the docstring of usb_ep_queue(), this should not happen:\n\n\u0026quot;Note that @req\u0026apos;s -\u0026gt;complete() callback must never be called from within\nusb_ep_queue() as that can create deadlock situations.\u0026quot;\n\nIn fact, a hardware lockup might occur in the following sequence:\n\n1. The gadget is initialized using musb_gadget_enable().\n2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an\n   interrupt.\n3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an\n   empty queue (next_request() returns NULL). The interrupt flag has\n   already been cleared by the glue layer handler, but the RXPKTRDY flag\n   remains set.\n4. The first request is enqueued using usb_ep_queue(), leading to the call\n   of req-\u0026gt;complete(), as shown in the call trace above.\n5. If the callback enables IRQs and another packet is waiting, step (3)\n   repeats. The request queue is empty because usb_g_giveback() removes the\n   request before invoking the callback.\n6. The endpoint remains locked up, as the interrupt triggered by hardware\n   setting the RXPKTRDY flag has been handled, but the flag itself remains\n   set.\n\nFor this scenario to occur, it is only necessary for IRQs to be enabled at\nsome point during the complete callback. This happens with the USB Ethernet\ngadget, whose rx_complete() callback calls netif_rx(). If called in the\ntask context, netif_rx() disables the bottom halves (BHs). When the BHs are\nre-enabled, IRQs are also enabled to allow soft IRQs to be processed. The\ngadget itself is initialized at module load (or at boot if built-in), but\nthe first request is enqueued when the network interface is brought up,\ntriggering rx_complete() in the task context via ioctl(). If a packet\narrives while the interface is down, it can prevent the interface from\nreceiving any further packets from the USB host.\n\nThe situation is quite complicated with many parties involved. This\nparticular issue can be resolved in several possible ways:\n\n1. Ensure that callbacks never enable IRQs. This would be difficult to\n   enforce, as discovering how netif_rx() interacts with interrupts was\n   already quite challenging and u_ether is not the only function driver.\n   Similar \u0026quot;bugs\u0026quot; could be hidden in other drivers as well.\n2. Disable MUSB interrupts in musb_g_giveback() before calling the callback\n   and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),\n   for example). This would ensure that MUSB interrupts are not handled\n   during the callback, even if IRQs are enabled. In fact, it would allow\n   IRQs to be enabled when releasing the lock. However, this feels like an\n   inelegant hack.\n3. Modify the interrupt handler to clear the RXPKTRDY flag if the request\n   queue is empty. While this approach also feels like a hack, it wastes\n   CPU time by attempting to handle incoming packets when the software is\n   not ready to process them.\n4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().\n   This ensures that the hardware can receive packets when there is at\n   least one request in the queue. Once I\n---truncated---(CVE-2024-56687)\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\npowerpc/pseries: Fix dtl_access_lock to be a rw_semaphore\n\nThe dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because\nthe code calls kmalloc() while holding it, which can sleep:\n\n  # echo 1 \u0026gt; /proc/powerpc/vcpudispatch_stats\n  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh\n  preempt_count: 1, expected: 0\n  3 locks held by sh/199:\n   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438\n   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4\n   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4\n  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152\n  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries\n  Call Trace:\n    dump_stack_lvl+0x130/0x148 (unreliable)\n    __might_resched+0x174/0x410\n    kmem_cache_alloc_noprof+0x340/0x3d0\n    alloc_dtl_buffers+0x124/0x1ac\n    vcpudispatch_stats_write+0x2a8/0x5f4\n    proc_reg_write+0xf4/0x150\n    vfs_write+0xfc/0x438\n    ksys_write+0x88/0x148\n    system_call_exception+0x1c4/0x5a0\n    system_call_common+0xf4/0x258(CVE-2024-56701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: protect link down work from execute after lgr freed\n\nlink down work may be scheduled before lgr freed but execute\nafter lgr freed, which may result in crash. So it is need to\nhold a reference before shedule link down work, and put the\nreference after work executed or canceled.\n\nThe relevant crash call stack as follows:\n list_del corruption. prev-\u0026gt;next should be ffffb638c9c0fe20,\n    but was 0000000000000000\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:51!\n invalid opcode: 0000 [#1] SMP NOPTI\n CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1\n Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014\n Workqueue: events smc_link_down_work [smc]\n RIP: 0010:__list_del_entry_valid.cold+0x31/0x47\n RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086\n RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000\n RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80\n RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38\n R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002\n R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0\n FS:  0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  rwsem_down_write_slowpath+0x17e/0x470\n  smc_link_down_work+0x3c/0x60 [smc]\n  process_one_work+0x1ac/0x350\n  worker_thread+0x49/0x2f0\n  ? rescuer_thread+0x360/0x360\n  kthread+0x118/0x140\n  ? __kthread_bind_mask+0x60/0x60\n  ret_from_fork+0x1f/0x30(CVE-2024-56718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: Initialize cfid-\u0026gt;tcon before performing network ops\n\nAvoid leaking a tcon ref when a lease break races with opening the\ncached directory. Processing the leak break might take a reference to\nthe tcon in cached_dir_lease_break() and then fail to release the ref in\ncached_dir_offload_close, since cfid-\u0026gt;tcon is still NULL.(CVE-2024-56729)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: check folio mapping after unlock in relocate_one_folio()\n\nWhen we call btrfs_read_folio() to bring a folio uptodate, we unlock the\nfolio. The result of that is that a different thread can modify the\nmapping (like remove it with invalidate) before we call folio_lock().\nThis results in an invalid page and we need to try again.\n\nIn particular, if we are relocating concurrently with aborting a\ntransaction, this can result in a crash like the following:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP\n  CPU: 76 PID: 1411631 Comm: kworker/u322:5\n  Workqueue: events_unbound btrfs_reclaim_bgs_work\n  RIP: 0010:set_page_extent_mapped+0x20/0xb0\n  RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246\n  RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000\n  RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880\n  RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0\n  R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000\n  R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff\n  FS:  0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n  \u0026lt;TASK\u0026gt;\n  ? __die+0x78/0xc0\n  ? page_fault_oops+0x2a8/0x3a0\n  ? __switch_to+0x133/0x530\n  ? wq_worker_running+0xa/0x40\n  ? exc_page_fault+0x63/0x130\n  ? asm_exc_page_fault+0x22/0x30\n  ? set_page_extent_mapped+0x20/0xb0\n  relocate_file_extent_cluster+0x1a7/0x940\n  relocate_data_extent+0xaf/0x120\n  relocate_block_group+0x20f/0x480\n  btrfs_relocate_block_group+0x152/0x320\n  btrfs_relocate_chunk+0x3d/0x120\n  btrfs_reclaim_bgs_work+0x2ae/0x4e0\n  process_scheduled_works+0x184/0x370\n  worker_thread+0xc6/0x3e0\n  ? blk_add_timer+0xb0/0xb0\n  kthread+0xae/0xe0\n  ? flush_tlb_kernel_range+0x90/0x90\n  ret_from_fork+0x2f/0x40\n  ? flush_tlb_kernel_range+0x90/0x90\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\n\nThis occurs because cleanup_one_transaction() calls\ndestroy_delalloc_inodes() which calls invalidate_inode_pages2() which\ntakes the folio_lock before setting mapping to NULL. We fail to check\nthis, and subsequently call set_extent_mapping(), which assumes that\nmapping != NULL (in fact it asserts that in debug mode)\n\nNote that the \u0026quot;fixes\u0026quot; patch here is not the one that introduced the\nrace (the very first iteration of this code from 2009) but a more recent\nchange that made this particular crash happen in practice..(CVE-2024-56758)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg\n\nSyzbot reports [1] an uninitialized value issue found by KMSAN in\ndib3000_read_reg().\n\nLocal u8 rb[2] is used in i2c_transfer() as a read buffer; in case\nthat call fails, the buffer may end up with some undefined values.\n\nSince no elaborate error handling is expected in dib3000_write_reg(),\nsimply zero out rb buffer to mitigate the problem.\n\n[1] Syzkaller report\ndvb-usb: bulk message failed: -22 (6/0)\n=====================================================\nBUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31\n dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290\n dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]\n dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]\n dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310\n dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110\n...\nLocal variable rb created at:\n dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54\n dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n...(CVE-2024-56769)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n                   NFS CLIENT\nthread1                             thread2\nopen(\u0026quot;file\u0026quot;)\n...\nnfs4_do_open\n _nfs4_do_open\n  _nfs4_open_and_get_state\n   _nfs4_proc_open\n    nfs4_run_open_task\n     /* rpc_task1 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\n                                    umount -f\n                                    nfs_umount_begin\n                                     rpc_killall_tasks\n                                      rpc_signal_task\n     rpc_task1 been wakeup\n     and return -512\n _nfs4_do_open // while loop\n    ...\n    nfs4_run_open_task\n     /* rpc_task2 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n                    NFS SERVER\nnfsd1                  nfsd2       echo 0 \u0026gt; /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n  find_or_alloc_open_stateowner\n   // alloc oo1, stateid1\n                       nfsd4_open\n                        nfsd4_process_open1\n                        find_or_alloc_open_stateowner\n                        // find oo1, without NFS4_OO_CONFIRMED\n                         release_openowner\n                          unhash_openowner_locked\n                          list_del_init(\u0026amp;oo-\u0026gt;oo_perclient)\n                          // cannot find this oo\n                          // from client, LEAK!!!\n                         alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n  init_open_stateid\n  // associate oo1\n  // with stateid1, stateid1 LEAK!!!\n  nfs4_get_vfs_file\n  // alloc nfsd_file1 and nfsd_file_mark1\n  // all LEAK!!!\n\n                         nfsd4_process_open2\n                         ...\n\n                                    write_threads\n                                     ...\n                                     nfsd_destroy_serv\n                                      nfsd_shutdown_net\n                                       nfs4_state_shutdown_net\n                                        nfs4_state_destroy_net\n                                         destroy_client\n                                          __destroy_client\n                                          // won\u0026apos;t find oo1!!!\n                                     nfsd_shutdown_generic\n                                      nfsd_file_cache_shutdown\n                                       kmem_cache_destroy\n                                       for nfsd_file_slab\n                                       and nfsd_file_mark_slab\n                                       // bark since nfsd_file1\n                                       // and nfsd_file_mark1\n                                       // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: imx6: Fix suspend/resume support on i.MX6QDL\n\nThe suspend/resume functionality is currently broken on the i.MX6QDL\nplatform, as documented in the NXP errata (ERR005723):\n\n  https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf\n\nThis patch addresses the issue by sharing most of the suspend/resume\nsequences used by other i.MX devices, while avoiding modifications to\ncritical registers that disrupt the PCIe functionality. It targets the\nsame problem as the following downstream commit:\n\n  https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995\n\nUnlike the downstream commit, this patch also resets the connected PCIe\ndevice if possible. Without this reset, certain drivers, such as ath10k\nor iwlwifi, will crash on resume. The device reset is also done by the\ndriver on other i.MX platforms, making this patch consistent with\nexisting practices.\n\nUpon resuming, the kernel will hang and display an error. Here\u0026apos;s an\nexample of the error encountered with the ath10k driver:\n\n  ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible\n  Unhandled fault: imprecise external abort (0x1406) at 0x0106f944\n\nWithout this patch, suspend/resume will fail on i.MX6QDL devices if a\nPCIe device is connected.\n\n[kwilczynski: commit log, added tag for stable releases](CVE-2024-57809)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL\n\nCurrently tagged_addr_ctrl_set() doesn\u0026apos;t initialize the temporary \u0026apos;ctrl\u0026apos;\nvariable, and a SETREGSET call with a length of zero will leave this\nuninitialized. Consequently tagged_addr_ctrl_set() will consume an\narbitrary value, potentially leaking up to 64 bits of memory from the\nkernel stack. The read is limited to a specific slot on the stack, and\nthe issue does not provide a write mechanism.\n\nAs set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and\nrejects other values, a partial SETREGSET attempt will randomly succeed\nor fail depending on the value of the uninitialized value, and the\nexposure is significantly limited.\n\nFix this by initializing the temporary value before copying the regset\nfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,\nNT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing\nvalue of the tagged address ctrl will be retained.\n\nThe NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the\nuser_aarch64_view used by a native AArch64 task to manipulate another\nnative AArch64 task. As get_tagged_addr_ctrl() only returns an error\nvalue when called for a compat task, tagged_addr_ctrl_get() and\ntagged_addr_ctrl_set() should never observe an error value from\nget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that\nsuch an error would be unexpected, and error handlnig is not missing in\neither case.(CVE-2024-57874)\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)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ti-ads8688: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57906)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: vcnl4035: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to userspace from a\ntriggered buffer, but it does not set an initial value for the single\ndata element, which is an u16 aligned to 8 bytes. That leaves at least\n4 bytes uninitialized even after writing an integer value with\nregmap_read().\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntopology: Keep the cpumask unchanged when printing cpumap\n\nDuring fuzz testing, the following warning was discovered:\n\n different return values (15 and 11) from vsnprintf(\u0026quot;%*pbl\n \u0026quot;, ...)\n\n test:keyward is WARNING in kvasprintf\n WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130\n Call Trace:\n  kvasprintf+0x121/0x130\n  kasprintf+0xa6/0xe0\n  bitmap_print_to_buf+0x89/0x100\n  core_siblings_list_read+0x7e/0xb0\n  kernfs_file_read_iter+0x15b/0x270\n  new_sync_read+0x153/0x260\n  vfs_read+0x215/0x290\n  ksys_read+0xb9/0x160\n  do_syscall_64+0x56/0x100\n  entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe call trace shows that kvasprintf() reported this warning during the\nprinting of core_siblings_list. kvasprintf() has several steps:\n\n (1) First, calculate the length of the resulting formatted string.\n\n (2) Allocate a buffer based on the returned length.\n\n (3) Then, perform the actual string formatting.\n\n (4) Check whether the lengths of the formatted strings returned in\n     steps (1) and (2) are consistent.\n\nIf the core_cpumask is modified between steps (1) and (3), the lengths\nobtained in these two steps may not match. Indeed our test includes cpu\nhotplugging, which should modify core_cpumask while printing.\n\nTo fix this issue, cache the cpumask into a temporary variable before\ncalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged\nduring the printing process.(CVE-2024-57917)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add check for granularity in dml ceil/floor helpers\n\n[Why]\nWrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()\nshould check for granularity is non zero to avoid assert and\ndivide-by-zero error in dcn_bw_ functions.\n\n[How]\nAdd check for granularity 0.\n\n(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)(CVE-2024-57922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Set private-\u0026gt;all_drm_private[i]-\u0026gt;drm to NULL if mtk_drm_bind returns err\n\nThe pointer need to be set to NULL, otherwise KASAN complains about\nuse-after-free. Because in mtk_drm_bind, all private\u0026apos;s drm are set\nas follows.\n\nprivate-\u0026gt;all_drm_private[i]-\u0026gt;drm = drm;\n\nAnd drm will be released by drm_dev_put in case mtk_drm_kms_init returns\nfailure. However, the shutdown path still accesses the previous allocated\nmemory in drm_atomic_helper_shutdown.\n\n[   84.874820] watchdog: watchdog0: watchdog did not stop!\n[   86.512054] ==================================================================\n[   86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378\n[   86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1\n[   86.515213]\n[   86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55\n[   86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022\n[   86.517960] Call trace:\n[   86.518333]  show_stack+0x20/0x38 (C)\n[   86.518891]  dump_stack_lvl+0x90/0xd0\n[   86.519443]  print_report+0xf8/0x5b0\n[   86.519985]  kasan_report+0xb4/0x100\n[   86.520526]  __asan_report_load8_noabort+0x20/0x30\n[   86.521240]  drm_atomic_helper_shutdown+0x33c/0x378\n[   86.521966]  mtk_drm_shutdown+0x54/0x80\n[   86.522546]  platform_shutdown+0x64/0x90\n[   86.523137]  device_shutdown+0x260/0x5b8\n[   86.523728]  kernel_restart+0x78/0xf0\n[   86.524282]  __do_sys_reboot+0x258/0x2f0\n[   86.524871]  __arm64_sys_reboot+0x90/0xd8\n[   86.525473]  invoke_syscall+0x74/0x268\n[   86.526041]  el0_svc_common.constprop.0+0xb0/0x240\n[   86.526751]  do_el0_svc+0x4c/0x70\n[   86.527251]  el0_svc+0x4c/0xc0\n[   86.527719]  el0t_64_sync_handler+0x144/0x168\n[   86.528367]  el0t_64_sync+0x198/0x1a0\n[   86.528920]\n[   86.529157] The buggy address belongs to the physical page:\n[   86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc\n[   86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)\n[   86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000\n[   86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000\n[   86.534511] page dumped because: kasan: bad access detected\n[   86.535323]\n[   86.535559] Memory state around the buggy address:\n[   86.536265]  ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.537314]  ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.538363] \u0026gt;ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.544733]                                                           ^\n[   86.551057]  ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.557510]  ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.563928] ==================================================================\n[   86.571093] Disabling lock debugging due to kernel taint\n[   86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b\n[   86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]\n...(CVE-2024-57926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure shadow stack is active before \u0026quot;getting\u0026quot; registers\n\nThe x86 shadow stack support has its own set of registers. Those registers\nare XSAVE-managed, but they are \u0026quot;supervisor state components\u0026quot; which means\nthat userspace can not touch them with XSAVE/XRSTOR.  It also means that\nthey are not accessible from the existing ptrace ABI for XSAVE state.\nThus, there is a new ptrace get/set interface for it.\n\nThe regset code that ptrace uses provides an -\u0026gt;active() handler in\naddition to the get/set ones. For shadow stack this -\u0026gt;active() handler\nverifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the\nthread struct. The -\u0026gt;active() handler is checked from some call sites of\nthe regset get/set handlers, but not the ptrace ones. This was not\nunderstood when shadow stack support was put in place.\n\nAs a result, both the set/get handlers can be called with\nXFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to\nreturn NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an\nssp_active() check to avoid surprising the kernel with shadow stack\nbehavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That\ncheck just happened to avoid the warning.\n\nBut the -\u0026gt;get() side wasn\u0026apos;t so lucky. It can be called with shadow stacks\ndisabled, triggering the warning in practice, as reported by Christina\nSchimpe:\n\nWARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0\n[...]\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6e/0x80\n? ssp_get+0x89/0xa0\n? __warn+0x91/0x150\n? ssp_get+0x89/0xa0\n? report_bug+0x19d/0x1b0\n? handle_bug+0x46/0x80\n? exc_invalid_op+0x1d/0x80\n? asm_exc_invalid_op+0x1f/0x30\n? __pfx_ssp_get+0x10/0x10\n? ssp_get+0x89/0xa0\n? ssp_get+0x52/0xa0\n__regset_get+0xad/0xf0\ncopy_regset_to_user+0x52/0xc0\nptrace_regset+0x119/0x140\nptrace_request+0x13c/0x850\n? wait_task_inactive+0x142/0x1d0\n? do_syscall_64+0x6d/0x90\narch_ptrace+0x102/0x300\n[...]\n\nEnsure that shadow stacks are active in a thread before looking them up\nin the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are\nset at the same time, the active check ensures that there will be\nsomething to find in the XSAVE buffer.\n\n[ dhansen: changelog/subject tweaks ](CVE-2025-21632)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid NULL pointer dereference if no valid extent tree\n\n[BUG]\nSyzbot reported a crash with the following call trace:\n\n  BTRFS info (device loop0): scrub: started on devid 1\n  BUG: kernel NULL pointer dereference, address: 0000000000000208\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0\n  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G           O       6.13.0-rc4-custom+ #206\n  Tainted: [O]=OOT_MODULE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n  RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]\n   scrub_simple_mirror+0x175/0x260 [btrfs]\n   scrub_stripe+0x5d4/0x6c0 [btrfs]\n   scrub_chunk+0xbb/0x170 [btrfs]\n   scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]\n   btrfs_scrub_dev+0x240/0x600 [btrfs]\n   btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]\n   ? do_sys_openat2+0xa5/0xf0\n   __x64_sys_ioctl+0x97/0xc0\n   do_syscall_64+0x4f/0x120\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   \u0026lt;/TASK\u0026gt;\n\n[CAUSE]\nThe reproducer is using a corrupted image where extent tree root is\ncorrupted, thus forcing to use \u0026quot;rescue=all,ro\u0026quot; mount option to mount the\nimage.\n\nThen it triggered a scrub, but since scrub relies on extent tree to find\nwhere the data/metadata extents are, scrub_find_fill_first_stripe()\nrelies on an non-empty extent root.\n\nBut unfortunately scrub_find_fill_first_stripe() doesn\u0026apos;t really expect\nan NULL pointer for extent root, it use extent_root to grab fs_info and\ntriggered a NULL pointer dereference.\n\n[FIX]\nAdd an extra check for a valid extent root at the beginning of\nscrub_find_fill_first_stripe().\n\nThe new error path is introduced by 42437a6386ff (\u0026quot;btrfs: introduce\nmount option rescue=ignorebadroots\u0026quot;), but that\u0026apos;s pretty old, and later\ncommit b979547513ff (\u0026quot;btrfs: scrub: introduce helper to find and fill\nsector info for a scrub_stripe\u0026quot;) changed how we do scrub.\n\nSo for kernels older than 6.6, the fix will need manual backport.(CVE-2025-21658)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/bpf: return early if transport is not assigned\n\nSome of the core functions can only be called if the transport\nhas been assigned.\n\nAs Michal reported, a socket might have the transport at NULL,\nfor example after a failed connect(), causing the following trace:\n\n    BUG: kernel NULL pointer dereference, address: 00000000000000a0\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0\n    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+\n    RIP: 0010:vsock_connectible_has_data+0x1f/0x40\n    Call Trace:\n     vsock_bpf_recvmsg+0xca/0x5e0\n     sock_recvmsg+0xb9/0xc0\n     __sys_recvfrom+0xb3/0x130\n     __x64_sys_recvfrom+0x20/0x30\n     do_syscall_64+0x93/0x180\n     entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nSo we need to check the `vsk-\u0026gt;transport` in vsock_bpf_recvmsg(),\nespecially for connected sockets (stream/seqpacket) as we already\ndo in __vsock_connectible_recvmsg().(CVE-2025-21670)",
  "id": "OESA-2025-1097",
  "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-1097"
    },
    {
      "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-36479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36916"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38571"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38575"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38585"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39474"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39495"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40937"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40989"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42110"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42251"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43857"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43870"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43875"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43876"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43877"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43880"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43881"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44957"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44972"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45001"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45005"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45007"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46672"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46680"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46693"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46694"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46711"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46741"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46847"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46864"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46865"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47730"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47735"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49864"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49888"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49926"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49939"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49951"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49953"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49987"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49998"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50035"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50077"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50096"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50110"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50111"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50136"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50147"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50160"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50175"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50176"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50181"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50189"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50221"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50231"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50232"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50240"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50252"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50256"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50304"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53051"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53058"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53093"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53094"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53097"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53100"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53106"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53109"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53113"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53119"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53120"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53121"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53122"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53123"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53124"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53135"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53138"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53139"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53140"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53144"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53145"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53166"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53206"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53207"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53209"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53223"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53237"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54193"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56557"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56567"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56589"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56590"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56640"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56641"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56653"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56687"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56701"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56718"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56729"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56769"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57874"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57906"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57910"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57922"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57926"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21632"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21658"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21670"
    }
  ],
  "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-26952",
    "CVE-2024-26954",
    "CVE-2024-36479",
    "CVE-2024-36916",
    "CVE-2024-37021",
    "CVE-2024-38571",
    "CVE-2024-38575",
    "CVE-2024-38585",
    "CVE-2024-38621",
    "CVE-2024-39474",
    "CVE-2024-39482",
    "CVE-2024-39495",
    "CVE-2024-40924",
    "CVE-2024-40937",
    "CVE-2024-40949",
    "CVE-2024-40961",
    "CVE-2024-40965",
    "CVE-2024-40989",
    "CVE-2024-41001",
    "CVE-2024-41032",
    "CVE-2024-42110",
    "CVE-2024-42251",
    "CVE-2024-43857",
    "CVE-2024-43870",
    "CVE-2024-43875",
    "CVE-2024-43876",
    "CVE-2024-43877",
    "CVE-2024-43880",
    "CVE-2024-43881",
    "CVE-2024-44957",
    "CVE-2024-44968",
    "CVE-2024-44972",
    "CVE-2024-44975",
    "CVE-2024-45001",
    "CVE-2024-45005",
    "CVE-2024-45007",
    "CVE-2024-45012",
    "CVE-2024-45022",
    "CVE-2024-46672",
    "CVE-2024-46680",
    "CVE-2024-46693",
    "CVE-2024-46694",
    "CVE-2024-46711",
    "CVE-2024-46741",
    "CVE-2024-46833",
    "CVE-2024-46847",
    "CVE-2024-46864",
    "CVE-2024-46865",
    "CVE-2024-47730",
    "CVE-2024-47735",
    "CVE-2024-49864",
    "CVE-2024-49888",
    "CVE-2024-49926",
    "CVE-2024-49939",
    "CVE-2024-49946",
    "CVE-2024-49951",
    "CVE-2024-49953",
    "CVE-2024-49987",
    "CVE-2024-49988",
    "CVE-2024-49998",
    "CVE-2024-50035",
    "CVE-2024-50077",
    "CVE-2024-50096",
    "CVE-2024-50110",
    "CVE-2024-50111",
    "CVE-2024-50136",
    "CVE-2024-50147",
    "CVE-2024-50160",
    "CVE-2024-50175",
    "CVE-2024-50176",
    "CVE-2024-50181",
    "CVE-2024-50183",
    "CVE-2024-50189",
    "CVE-2024-50220",
    "CVE-2024-50221",
    "CVE-2024-50231",
    "CVE-2024-50232",
    "CVE-2024-50240",
    "CVE-2024-50252",
    "CVE-2024-50256",
    "CVE-2024-50295",
    "CVE-2024-50296",
    "CVE-2024-50304",
    "CVE-2024-53051",
    "CVE-2024-53058",
    "CVE-2024-53091",
    "CVE-2024-53093",
    "CVE-2024-53094",
    "CVE-2024-53097",
    "CVE-2024-53100",
    "CVE-2024-53106",
    "CVE-2024-53109",
    "CVE-2024-53113",
    "CVE-2024-53119",
    "CVE-2024-53120",
    "CVE-2024-53121",
    "CVE-2024-53122",
    "CVE-2024-53123",
    "CVE-2024-53124",
    "CVE-2024-53135",
    "CVE-2024-53138",
    "CVE-2024-53139",
    "CVE-2024-53140",
    "CVE-2024-53144",
    "CVE-2024-53145",
    "CVE-2024-53166",
    "CVE-2024-53201",
    "CVE-2024-53206",
    "CVE-2024-53207",
    "CVE-2024-53209",
    "CVE-2024-53223",
    "CVE-2024-53237",
    "CVE-2024-54193",
    "CVE-2024-56557",
    "CVE-2024-56567",
    "CVE-2024-56588",
    "CVE-2024-56589",
    "CVE-2024-56590",
    "CVE-2024-56614",
    "CVE-2024-56623",
    "CVE-2024-56640",
    "CVE-2024-56641",
    "CVE-2024-56653",
    "CVE-2024-56677",
    "CVE-2024-56687",
    "CVE-2024-56688",
    "CVE-2024-56701",
    "CVE-2024-56718",
    "CVE-2024-56729",
    "CVE-2024-56758",
    "CVE-2024-56769",
    "CVE-2024-56779",
    "CVE-2024-57809",
    "CVE-2024-57874",
    "CVE-2024-57892",
    "CVE-2024-57906",
    "CVE-2024-57910",
    "CVE-2024-57917",
    "CVE-2024-57922",
    "CVE-2024-57926",
    "CVE-2025-21632",
    "CVE-2025-21658",
    "CVE-2025-21670"
  ]
}