{"id":"OESA-2024-2367","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add NULL pointer check for kzalloc\r\n\r\n[Why & How]\nCheck return pointer of kzalloc before using it.(CVE-2024-42122)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: gup: stop abusing try_grab_folio\r\n\r\nA kernel warning was reported when pinning folio in CMA memory when\nlaunching SEV virtual machine.  The splat looks like:\r\n\r\n[  464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520\n[  464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6\n[  464.325477] RIP: 0010:__get_user_pages+0x423/0x520\n[  464.325515] Call Trace:\n[  464.325520]  <TASK>\n[  464.325523]  ? __get_user_pages+0x423/0x520\n[  464.325528]  ? __warn+0x81/0x130\n[  464.325536]  ? __get_user_pages+0x423/0x520\n[  464.325541]  ? report_bug+0x171/0x1a0\n[  464.325549]  ? handle_bug+0x3c/0x70\n[  464.325554]  ? exc_invalid_op+0x17/0x70\n[  464.325558]  ? asm_exc_invalid_op+0x1a/0x20\n[  464.325567]  ? __get_user_pages+0x423/0x520\n[  464.325575]  __gup_longterm_locked+0x212/0x7a0\n[  464.325583]  internal_get_user_pages_fast+0xfb/0x190\n[  464.325590]  pin_user_pages_fast+0x47/0x60\n[  464.325598]  sev_pin_memory+0xca/0x170 [kvm_amd]\n[  464.325616]  sev_mem_enc_register_region+0x81/0x130 [kvm_amd]\r\n\r\nPer the analysis done by yangge, when starting the SEV virtual machine, it\nwill call pin_user_pages_fast(..., FOLL_LONGTERM, ...) to pin the memory. \nBut the page is in CMA area, so fast GUP will fail then fallback to the\nslow path due to the longterm pinnalbe check in try_grab_folio().\r\n\r\nThe slow path will try to pin the pages then migrate them out of CMA area.\nBut the slow path also uses try_grab_folio() to pin the page, it will\nalso fail due to the same check then the above warning is triggered.\r\n\r\nIn addition, the try_grab_folio() is supposed to be used in fast path and\nit elevates folio refcount by using add ref unless zero.  We are guaranteed\nto have at least one stable reference in slow path, so the simple atomic add\ncould be used.  The performance difference should be trivial, but the\nmisuse may be confusing and misleading.\r\n\r\nRedefined try_grab_folio() to try_grab_folio_fast(), and try_grab_page()\nto try_grab_folio(), and use them in the proper paths.  This solves both\nthe abuse and the kernel warning.\r\n\r\nThe proper naming makes their usecase more clear and should prevent from\nabusing in the future.\r\n\r\npeterx said:\r\n\r\n: The user will see the pin fails, for gpu-slow it further triggers the WARN\n: right below that failure (as in the original report):\n: \n:         folio = try_grab_folio(page, page_increm - 1,\n:                                 foll_flags);\n:         if (WARN_ON_ONCE(!folio)) { <------------------------ here\n:                 /*\n:                         * Release the 1st page ref if the\n:                         * folio is problematic, fail hard.\n:                         */\n:                 gup_put_folio(page_folio(page), 1,\n:                                 foll_flags);\n:                 ret = -EFAULT;\n:                 goto out;\n:         }\r\n\r\n[1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/\r\n\r\n[shy828301@gmail.com: fix implicit declaration of function try_grab_folio_fast]\n  Link: https://lkml.kernel.org/r/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com(CVE-2024-44943)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: sc16is7xx: fix TX fifo corruption\r\n\r\nSometimes, when a packet is received on channel A at almost the same time\nas a packet is about to be transmitted on channel B, we observe with a\nlogic analyzer that the received packet on channel A is transmitted on\nchannel B. In other words, the Tx buffer data on channel B is corrupted\nwith data from channel A.\r\n\r\nThe problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change\nEFR lock to operate on each channels"), which changed the EFR locking to\noperate on each channel instead of chip-wise.\r\n\r\nThis commit has introduced a regression, because the EFR lock is used not\nonly to protect the EFR registers access, but also, in a very obscure and\nundocumented way, to protect access to the data buffer, which is shared by\nthe Tx and Rx handlers, but also by each channel of the IC.\r\n\r\nFix this regression first by switching to kfifo_out_linear_ptr() in\nsc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.\r\n\r\nSecondly, replace the chip-wise Rx buffer with a separate Rx buffer for\neach channel.(CVE-2024-44951)\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\npinctrl: single: fix potential NULL dereference in pcs_get_function()\r\n\r\npinmux_generic_get_function() can return NULL and the pointer 'function'\nwas dereferenced without checking against NULL. Add checking of pointer\n'function' in pcs_get_function().\r\n\r\nFound by code review.(CVE-2024-46685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthunderbolt: Mark XDomain as unplugged when router is removed\r\n\r\nI noticed that when we do discrete host router NVM upgrade and it gets\nhot-removed from the PCIe side as a result of NVM firmware authentication,\nif there is another host connected with enabled paths we hang in tearing\nthem down. This is due to fact that the Thunderbolt networking driver\nalso tries to cleanup the paths and ends up blocking in\ntb_disconnect_xdomain_paths() waiting for the domain lock.\r\n\r\nHowever, at this point we already cleaned the paths in tb_stop() so\nthere is really no need for tb_disconnect_xdomain_paths() to do that\nanymore. Furthermore it already checks if the XDomain is unplugged and\nbails out early so take advantage of that and mark the XDomain as\nunplugged when we remove the parent router.(CVE-2024-46702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()\r\n\r\nWhen two UBLK_CMD_START_USER_RECOVERY commands are submitted, the\nfirst one sets 'ubq->ubq_daemon' to NULL, and the second one triggers\nWARN in ublk_queue_reinit() and subsequently a NULL pointer dereference\nissue.\r\n\r\nFix it by adding the check in ublk_ctrl_start_recovery() and return\nimmediately in case of zero 'ub->nr_queues_ready'.\r\n\r\n  BUG: kernel NULL pointer dereference, address: 0000000000000028\n  RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180\n  Call Trace:\n   <TASK>\n   ? __die+0x20/0x70\n   ? page_fault_oops+0x75/0x170\n   ? exc_page_fault+0x64/0x140\n   ? asm_exc_page_fault+0x22/0x30\n   ? ublk_ctrl_start_recovery.constprop.0+0x82/0x180\n   ublk_ctrl_uring_cmd+0x4f7/0x6c0\n   ? pick_next_task_idle+0x26/0x40\n   io_uring_cmd+0x9a/0x1b0\n   io_issue_sqe+0x193/0x3f0\n   io_wq_submit_work+0x9b/0x390\n   io_worker_handle_work+0x165/0x360\n   io_wq_worker+0xcb/0x2f0\n   ? finish_task_switch.isra.0+0x203/0x290\n   ? finish_task_switch.isra.0+0x203/0x290\n   ? __pfx_io_wq_worker+0x10/0x10\n   ret_from_fork+0x2d/0x50\n   ? __pfx_io_wq_worker+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   </TASK>(CVE-2024-46735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg="func of_irq_parse_* +p"):\r\n\r\n  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n  OF:  intspec=4\n  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n  OF:  -> addrsize=3\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n  Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1\n  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n  Call trace:\n   dump_backtrace+0xdc/0x130\n   show_stack+0x1c/0x30\n   dump_stack_lvl+0x6c/0x84\n   print_report+0x150/0x448\n   kasan_report+0x98/0x140\n   __asan_load4+0x78/0xa0\n   of_irq_parse_raw+0x2b8/0x8d0\n   of_irq_parse_one+0x24c/0x270\n   parse_interrupts+0xc0/0x120\n   of_fwnode_add_links+0x100/0x2d0\n   fw_devlink_parse_fwtree+0x64/0xc0\n   device_add+0xb38/0xc30\n   of_device_add+0x64/0x90\n   of_platform_device_create_pdata+0xd0/0x170\n   of_platform_bus_create+0x244/0x600\n   of_platform_notify+0x1b0/0x254\n   blocking_notifier_call_chain+0x9c/0xd0\n   __of_changeset_entry_notify+0x1b8/0x230\n   __of_changeset_apply_notify+0x54/0xe4\n   of_overlay_fdt_apply+0xc04/0xd94\n   ...\r\n\r\n  The buggy address belongs to the object at ffffff81beca5600\n   which belongs to the cache kmalloc-128 of size 128\n  The buggy address is located 8 bytes inside of\n   128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n  The buggy address belongs to the physical page:\n  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n  flags: 0x8000000000010200(slab|head|zone=2)\n  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\r\n\r\n  Memory state around the buggy address:\n   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                        ^\n   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  OF:  -> got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\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\ndrm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]\r\n\r\n[WHY & HOW]\nnum_valid_sets needs to be checked to avoid a negative index when\naccessing reader_wm_sets[num_valid_sets - 1].\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommufd: Require drivers to supply the cache_invalidate_user ops\r\n\r\nIf drivers don't do this then iommufd will oops invalidation ioctls with\nsomething like:\r\n\r\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n  Mem abort info:\n    ESR = 0x0000000086000004\n    EC = 0x21: IABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x04: level 0 translation fault\n  user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101059000\n  [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n  Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n  Modules linked in:\n  CPU: 2 PID: 371 Comm: qemu-system-aar Not tainted 6.8.0-rc7-gde77230ac23a #9\n  Hardware name: linux,dummy-virt (DT)\n  pstate: 81400809 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=-c)\n  pc : 0x0\n  lr : iommufd_hwpt_invalidate+0xa4/0x204\n  sp : ffff800080f3bcc0\n  x29: ffff800080f3bcf0 x28: ffff0000c369b300 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n  x23: 0000000000000000 x22: 00000000c1e334a0 x21: ffff0000c1e334a0\n  x20: ffff800080f3bd38 x19: ffff800080f3bd58 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8240d6d8\n  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n  x8 : 0000001000000002 x7 : 0000fffeac1ec950 x6 : 0000000000000000\n  x5 : ffff800080f3bd78 x4 : 0000000000000003 x3 : 0000000000000002\n  x2 : 0000000000000000 x1 : ffff800080f3bcc8 x0 : ffff0000c6034d80\n  Call trace:\n   0x0\n   iommufd_fops_ioctl+0x154/0x274\n   __arm64_sys_ioctl+0xac/0xf0\n   invoke_syscall+0x48/0x110\n   el0_svc_common.constprop.0+0x40/0xe0\n   do_el0_svc+0x1c/0x28\n   el0_svc+0x34/0xb4\n   el0t_64_sync_handler+0x120/0x12c\n   el0t_64_sync+0x190/0x194\r\n\r\nAll existing drivers implement this op for nesting, this is mostly a\nbisection aid.(CVE-2024-46824)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: microchip: vcap: Fix use-after-free error in kunit test\r\n\r\nThis is a clear use-after-free error. We remove it, and rely on checking\nthe return code of vcap_del_rule.(CVE-2024-46831)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vfs: fix race between evice_inodes() and find_inode()&iput()  Hi, all  Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs.  Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super().  cpu0:                              cpu1: iput() // i_count is 1   ->spin_lock(inode)   ->dec i_count to 0   ->iput_final()                    generic_shutdown_super()     ->__inode_add_lru()               ->evict_inodes()       // cause some reason[2]           ->if (atomic_read(inode->i_count)) continue;       // return before                  // inode 261 passed the above check       // list_lru_add_obj()             // and then schedule out    ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set  btrfs_iget()   // after some function calls   ->find_inode()     // found the above inode 261     ->spin_lock(inode)    // check I_FREEING|I_WILL_FREE    // and passed       ->__iget()     ->spin_unlock(inode)                // schedule back                                         ->spin_lock(inode)                                         // check (I_NEW|I_FREEING|I_WILL_FREE) flags,                                         // passed and set I_FREEING iput()                                  ->spin_unlock(inode)   ->spin_lock(inode)     ->evict()   // dec i_count to 0   ->iput_final()     ->spin_unlock()     ->evict()  Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput().  To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.  If there is any misunderstanding, please let me know, thanks.  [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()  The psc->div[] array has psc->num_div elements.  These values come from when we call clk_hw_register_div().  It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on.  So this condition needs to be >= instead of > to prevent an out of bounds read.(CVE-2024-47686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  driver core: Fix a potential null-ptr-deref in module_add_driver()  Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name.  Fix it by releasing resources based on the exit path sequence.    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   Mem abort info:     ESR = 0x0000000096000005     EC = 0x25: DABT (current EL), IL = 32 bits     SET = 0, FnV = 0     EA = 0, S1PTW = 0     FSC = 0x05: level 1 translation fault   Data abort info:     ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000     CM = 0, WnR = 0, TnD = 0, TagAccess = 0     GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0   [dfffffc000000000] address between user and kernel address ranges   Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP   Dumping ftrace buffer:      (ftrace buffer empty)   Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region]   CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295   Hardware name: linux,dummy-virt (DT)   pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)   pc : strlen+0x24/0xb0   lr : kernfs_name_hash+0x1c/0xc4   sp : ffffffc081f97380   x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0   x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000   x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000   x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840   x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42   x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d   x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000   x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001   x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000   x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000   Call trace:    strlen+0x24/0xb0    kernfs_name_hash+0x1c/0xc4    kernfs_find_ns+0x118/0x2e8    kernfs_remove_by_name_ns+0x80/0x100    sysfs_remove_link+0x74/0xa8    module_add_driver+0x278/0x394    bus_add_driver+0x1f0/0x43c    driver_register+0xf4/0x3c0    __platform_driver_register+0x60/0x88    of_fpga_region_init+0x20/0x1000 [of_fpga_region]    do_one_initcall+0x110/0x788    do_init_module+0x1dc/0x5c8    load_module+0x3c38/0x4cac    init_module_from_file+0xd4/0x128    idempotent_init_module+0x2cc/0x528    __arm64_sys_finit_module+0xac/0x100    invoke_syscall+0x6c/0x258    el0_svc_common.constprop.0+0x160/0x22c    do_el0_svc+0x44/0x5c    el0_svc+0x48/0xb8    el0t_64_sync_handler+0x13c/0x158    el0t_64_sync+0x190/0x194   Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861)   ---[ end trace 0000000000000000 ]---   Kernel panic - not syncing: Oops: Fatal exception(CVE-2024-47688)\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'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->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->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.(CVE-2024-47691)\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 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), 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't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn'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]  <TASK> [ 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]  </TASK> [  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 "nilfs2: fix potential issues with empty b-tree nodes".  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: check stripe size compatibility on remount as well  We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0.  Fix that by adding the check in remount path as well.(CVE-2024-47700)\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:  <TASK>  __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 <48> 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  </TASK>  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:  drm/amd/display: Check link_res->hpo_dp_link_enc before using it  [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing.  This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-47704)\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:  iommufd: Protect against overflow of ALIGN() during iova allocation  Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this:     WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]    WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352    Modules linked in:    CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024    RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]    RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352    Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38    RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293    RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00    RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000    RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942    R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010    R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00    FS:  000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033    CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400    Call Trace:     <TASK>     iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274     iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421     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  Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.(CVE-2024-47719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/tdx: Fix "in-kernel MMIO" check  TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not.  However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO.  Ensure that the target MMIO address is within the kernel before decoding instruction.(CVE-2024-47727)\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->seq_nr and pd->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 "ModelName", a string that was previously parsed out of    some descriptor ("Vital Product Data") in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I    think parses some descriptor that was read from the device.    (But this case likely isn't exploitable because the format string looks    like "netronome/nic_%s", and there shouldn't be any *folders* starting    with "netronome/nic_". The previous case was different because there,    the "%s" 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 ".." path components.  For what it's worth, I went looking and haven'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:  KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock  Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations.  Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores).      CPU0                     CPU1                     CPU2 1   lock(&kvm->slots_lock); 2                                                     lock(&vcpu->mutex); 3                                                     lock(&kvm->srcu); 4                            lock(cpu_hotplug_lock); 5                            lock(kvm_lock); 6                            lock(&kvm->slots_lock); 7                                                     lock(cpu_hotplug_lock); 8   sync(&kvm->srcu);  Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier():    cpuhp_cpufreq_online()   |   -> cpufreq_online()      |      -> cpufreq_gov_performance_limits()         |         -> __cpufreq_driver_target()            |            -> __target_index()               |               -> cpufreq_freq_transition_begin()                  |                  -> cpufreq_notify_transition()                     |                     -> ... __kvmclock_cpufreq_notifier()  But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved.  E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual.  The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock.  For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list.    ======================================================   WARNING: possible circular locking dependency detected   6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S         O   ------------------------------------------------------   tee/35048 is trying to acquire lock:   ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]    but task is already holding lock:   ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]    which lock already depends on the new lock.     the existing dependency chain (in reverse order) is:    -> #3 (kvm_lock){+.+.}-{3:3}:          __mutex_lock+0x6a/0xb40          mutex_lock_nested+0x1f/0x30          kvm_dev_ioctl+0x4fb/0xe50 [kvm]          __se_sys_ioctl+0x7b/0xd0          __x64_sys_ioctl+0x21/0x30          x64_sys_call+0x15d0/0x2e60          do_syscall_64+0x83/0x160          entry_SYSCALL_64_after_hwframe+0x76/0x7e    -> #2 (cpu_hotplug_lock){++++}-{0:0}:          cpus_read_lock+0x2e/0xb0          static_key_slow_inc+0x16/0x30          kvm_lapic_set_base+0x6a/0x1c0 [kvm]          kvm_set_apic_base+0x8f/0xe0 [kvm]          kvm_set_msr_common+0x9ae/0xf80 [kvm]          vmx_set_msr+0xa54/0xbe0 [kvm_intel]          __kvm_set_msr+0xb6/0x1a0 [kvm]          kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]          kvm_vcpu_ioctl+0x485/0x5b0 [kvm]          __se_sys_ioctl+0x7b/0xd0          __x64_sys_ioctl+0x21/0x30          x64_sys_call+0x15d0/0x2e60          do_syscall_64+0x83/0x160          entry_SYSCALL_64_after_hwframe+0x76/0x7e    -> #1 (&kvm->srcu){.+.+}-{0:0}:          __synchronize_srcu+0x44/0x1a0        ---truncated---(CVE-2024-47744)\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'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'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: kirin: Fix buffer overflow in kirin_pcie_parse_port()  Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow.  Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access.  Found by Linux Verification Center (linuxtesting.org) with SVACE.  [kwilczynski: commit log](CVE-2024-47751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Fix H264 stateless decoder smatch warning  Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning  Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.(CVE-2024-47753)\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 && 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:  bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos  In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference.  Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space.  Simplest reproducer is a program:      r0 = 0     exit  With a single relocation record:      .insn_off = 0,          /* patch first instruction */     .type_id = 100500,      /* this type id does not exist */     .access_str_off = 6,    /* offset of string "0" */     .kind = BPF_CORE_TYPE_ID_LOCAL,  See the link for original reproducer or next commit for a test case.(CVE-2024-49850)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()  The kref_put() function will call nport->release if the refcount drops to zero.  The nport->release release function is _efc_nport_free() which frees "nport".  But then we dereference "nport" on the next line which is a use after free.  Re-order these lines to avoid the use after free.(CVE-2024-49852)\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'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->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements.  Thus the > needs to be >= to prevent an off by one access.(CVE-2024-49862)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cachefiles: fix dentry leak in cachefiles_open_file()  A dentry leak may be caused when a lookup cookie and a cull are concurrent:              P1             |             P2 ----------------------------------------------------------- cachefiles_lookup_cookie   cachefiles_look_up_object     lookup_one_positive_unlocked      // get dentry                             cachefiles_cull                               inode->i_flags |= S_KERNEL_FILE;     cachefiles_open_file       cachefiles_mark_inode_in_use         __cachefiles_mark_inode_in_use           can_use = false           if (!(inode->i_flags & S_KERNEL_FILE))             can_use = true    return false         return false         // Returns an error but doesn't put dentry  After that the following WARNING will be triggered when the backend folder is umounted:  ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img}  still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace:  <TASK>  d_walk+0xda/0x2b0  do_one_tree+0x20/0x40  shrink_dcache_for_umount+0x2c/0x90  generic_shutdown_super+0x20/0x160  kill_block_super+0x1a/0x40  ext4_kill_sb+0x22/0x40  deactivate_locked_super+0x35/0x80  cleanup_mnt+0x104/0x160 ==================================================================  Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released.  Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.(CVE-2024-49870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Input: adp5589-keys - fix NULL pointer dereference  We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.(CVE-2024-49871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition  In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work  can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work.  If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                         CPU1                                      | svc_i3c_master_hj_work svc_i3c_master_remove               | i3c_master_unregister(&master->base)| device_unregister(&master->dev)     | device_release                      | //free master->base                 |                                     | i3c_master_do_daa(&master->base)                                     | //use master->base  Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.(CVE-2024-49874)\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'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 > 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:  <TASK>  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->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(&neh->eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path->p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path->p_depth = 0        |    brelse(path[1].p_bh)  ---> 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(&neh->eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path->p_depth = 1              read_extent_tree_block  ---> return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path->p_depth == 1                  brelse(path[1].p_bh)  ---> 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:  <TASK>  __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'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 > 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:  <TASK>  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:  <TASK>  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->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 "BUG: KASAN: slab-out-of-bounds". 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]  <TASK> [   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]  </TASK> [   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 'path' is only used in ext4_ext_show_leaf(), remove 'path' 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: Initialize get_bytes_per_element's default to 1  Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream before comparing them  [WHAT & 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: Check null-initialized variables  [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing.  This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49898)\r\n\r\n(CVE-2024-49901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.(CVE-2024-49909)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream'  This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)(CVE-2024-49912)\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 'top_pipe_to_program' 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->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->clk_mgr` or `dc->clk_mgr->funcs` is null.  The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->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 'dc->clk_mgr' 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 & 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 &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &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->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->fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi->lcd_power(on, &fbi->fb.var)                                    | //use fbi->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:  wifi: ath12k: fix array out-of-bound access in SoC stats  Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access.  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1(CVE-2024-49931)\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 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <IRQ> 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'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 <0f> 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:  <TASK>  ? __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 <...snip...> 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 <...snip...> ? 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 '%pd' though, it'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 '%pd' 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->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:  wifi: cfg80211: Set correct chandef when starting CAC  When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC.  Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC.   Call Trace:   ? show_regs.part.0+0x14/0x16   ? __warn+0x67/0xc0   ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]   ? report_bug+0xa7/0x130   ? exc_overflow+0x30/0x30   ? handle_bug+0x27/0x50   ? exc_invalid_op+0x18/0x60   ? handle_exception+0xf6/0xf6   ? exc_overflow+0x30/0x30   ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]   ? exc_overflow+0x30/0x30   ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]   ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]   ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]   ? process_one_work+0x165/0x280   ? worker_thread+0x120/0x3f0   ? kthread+0xc2/0xf0   ? process_one_work+0x280/0x280   ? kthread_complete_and_exit+0x20/0x20   ? ret_from_fork+0x19/0x24  [shorten subject, remove OCB, reorder cases to match previous list](CVE-2024-49937)\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->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn'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->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->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't yet have session->tunnel set. Add a check for this case.(CVE-2024-49940)\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'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 "Next Free Rec:" had overshot the "Count:" 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:  ext4: fix timer use-after-free on failed mount  Syzbot has found an ODEBUG bug in ext4_fill_super  The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi).  When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called.  Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: i2c: ar0521: Use cansleep version of gpiod_set_value()  If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that.  ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace:  gpiod_set_value+0x74/0x7c  ar0521_power_on+0xcc/0x290 ...(CVE-2024-49961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: cancel dqi_sync_work before freeing oinfo  ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:  ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c  This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first.  BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: no need to continue when the number of entries is 1(CVE-2024-49967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: filesystems without casefold feature cannot be mounted with siphash  When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.(CVE-2024-49968)\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'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 "[uprobes]" 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'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->next)->dest.  Detect invalid geometry due to pull, by checking head_skb size. Don'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->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->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:  ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free  When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process:  ext4_ext_replay_update_ex   ppath = path   ext4_force_split_extent_at(&ppath)     ext4_split_extent_at       ext4_ext_insert_extent         ext4_ext_create_new_leaf           ext4_ext_grow_indepth             ext4_find_extent               if (depth > path[0].p_maxdepth)                 kfree(path)                 ---> path First freed                 *orig_path = path = NULL    ---> null ppath   kfree(path)                               ---> path double-free !!!  So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: fix double free issue during amdgpu module unload  Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module.  [  279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [  279.190577] Call Trace: [  279.190580]  <TASK> [  279.190582]  ? show_regs+0x69/0x80 [  279.190590]  ? die+0x3b/0x90 [  279.190595]  ? do_trap+0xc8/0xe0 [  279.190601]  ? do_error_trap+0x73/0xa0 [  279.190605]  ? __slab_free+0x152/0x2f0 [  279.190609]  ? exc_invalid_op+0x56/0x70 [  279.190616]  ? __slab_free+0x152/0x2f0 [  279.190642]  ? asm_exc_invalid_op+0x1f/0x30 [  279.190648]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [  279.191096]  ? __slab_free+0x152/0x2f0 [  279.191102]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [  279.191469]  kfree+0x260/0x2b0 [  279.191474]  dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [  279.191821]  link_destroy+0xd7/0x130 [amdgpu] [  279.192248]  dc_destruct+0x90/0x270 [amdgpu] [  279.192666]  dc_destroy+0x19/0x40 [amdgpu] [  279.193020]  amdgpu_dm_fini+0x16e/0x200 [amdgpu] [  279.193432]  dm_hw_fini+0x26/0x40 [amdgpu] [  279.193795]  amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [  279.194108]  amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [  279.194436]  amdgpu_pci_remove+0x40/0x80 [amdgpu] [  279.194632]  pci_device_remove+0x3a/0xa0 [  279.194638]  device_remove+0x40/0x70 [  279.194642]  device_release_driver_internal+0x1ad/0x210 [  279.194647]  driver_detach+0x4e/0xa0 [  279.194650]  bus_remove_driver+0x6f/0xf0 [  279.194653]  driver_unregister+0x33/0x60 [  279.194657]  pci_unregister_driver+0x44/0x90 [  279.194662]  amdgpu_exit+0x19/0x1f0 [amdgpu] [  279.194939]  __do_sys_delete_module.isra.0+0x198/0x2f0 [  279.194946]  __x64_sys_delete_module+0x16/0x20 [  279.194950]  do_syscall_64+0x58/0x120 [  279.194954]  entry_SYSCALL_64_after_hwframe+0x6e/0x76 [  279.194980]  </TASK>(CVE-2024-49989)\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:  block: fix integer overflow in BLKSECDISCARD  I independently rediscovered   commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155  block: fix overflow in blk_ioctl_discard()  but for secure erase.  Same problem:   uint64_t r[2] = {512, 18446744073709551104ULL};  ioctl(fd, BLKSECDISCARD, r);  will enter near infinite loop inside blkdev_issue_secure_erase():   a.out: attempt to access beyond end of device  loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048  bio_check_eod: 3286214 callbacks suppressed(CVE-2024-49994)\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() 'media_name' too large for 'name_parts->media_name' (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (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 ("[TIPC] Initial merge")  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's size from ReparseDataLength.  Function cifs_strndup_from_utf16() is currentlly accessing buf->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:  net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()  In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix system hang while resume with TBT monitor  [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume.  The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL.  It will mess up the pipe topology after resume.  [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default.  (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)(CVE-2024-50003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix i_data_sem unlock order in ext4_ind_migrate()  Fuzzing reports a possible deadlock in jbd2_log_wait_commit.  This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.  This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.  Found by Linux Verification Center (linuxtesting.org) with syzkaller.  Rule: add(CVE-2024-50006)\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 "ext_scan->tlv_buffer" 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:  cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value  cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50009)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  exfat: fix memory leak in exfat_load_bitmap()  If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix access to uninitialised lock in fc replay path  The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled:  INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x66/0x90  register_lock_class+0x759/0x7d0  __lock_acquire+0x85/0x2630  ? __find_get_block+0xb4/0x380  lock_acquire+0xd1/0x2d0  ? __ext4_journal_get_write_access+0xd5/0x160  _raw_spin_lock+0x33/0x40  ? __ext4_journal_get_write_access+0xd5/0x160  __ext4_journal_get_write_access+0xd5/0x160  ext4_reserve_inode_write+0x61/0xb0  __ext4_mark_inode_dirty+0x79/0x270  ? ext4_ext_replay_set_iblocks+0x2f8/0x450  ext4_ext_replay_set_iblocks+0x330/0x450  ext4_fc_replay+0x14c8/0x1540  ? jread+0x88/0x2e0  ? rcu_is_watching+0x11/0x40  do_one_pass+0x447/0xd00  jbd2_journal_recover+0x139/0x1b0  jbd2_journal_load+0x96/0x390  ext4_load_and_init_journal+0x253/0xd40  ext4_fill_super+0x2cc6/0x3180 ...  In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error().  Unfortunately, at this point this spinlock has not been initialized yet.  Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)\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->pos += iter->processed // iter->pos = 2M    ext4_iomap_begin     ext4_iomap_alloc // allocate 2~4M extents(written flag)   dax_iomap_iter    fatal_signal_pending   done = iter->pos - iocb->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:  kthread: unpark only parked kthread  Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state.  However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked.  As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning:   WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525   <TASK>   kthread_stop+0x17a/0x630 kernel/kthread.c:707   destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810   wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257   netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693   default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769   ops_exit_list net/core/net_namespace.c:178 [inline]   cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640   process_one_work kernel/workqueue.c:3231 [inline]   process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312   worker_thread+0x86d/0xd70 kernel/workqueue.c:3393   kthread+0x2f0/0x390 kernel/kthread.c:389   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244   </TASK>  Fix this with skipping unecessary unparking while stopping a kthread.(CVE-2024-50019)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  device-dax: correct pgoff align in dax_set_mapping()  pgoff should be aligned using ALIGN_DOWN() instead of ALIGN().  Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address.  It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault.  Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure.  In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end.   We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address.  It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly:   [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page:  Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at  200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page:  Recovered  It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue.   Joao added:  ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory).  I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e.  4K/2M/1G)(CVE-2024-50022)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Move flush_work initialization out of if block  After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue.  This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.  The following warning is observed while the fnic driver is loaded:  kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel:  <IRQ> kernel:  queue_work_on+0x3a/0x50 kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  __handle_irq_event_percpu+0x36/0x1a0 kernel:  handle_irq_event_percpu+0x30/0x70 kernel:  handle_irq_event+0x34/0x60 kernel:  handle_edge_irq+0x7e/0x1a0 kernel:  __common_interrupt+0x3b/0xb0 kernel:  common_interrupt+0x58/0xa0 kernel:  </IRQ>  It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.  This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: wd33c93: Don't use stale scsi_pointer value  A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.(CVE-2024-50026)\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:  Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync  This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace:  BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37  CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace:  <TASK>  dump_stack_lvl+0x5d/0x80  ? hci_enhanced_setup_sync+0x91b/0xa60  print_report+0x152/0x4c0  ? hci_enhanced_setup_sync+0x91b/0xa60  ? __virt_addr_valid+0x1fa/0x420  ? hci_enhanced_setup_sync+0x91b/0xa60  kasan_report+0xda/0x1b0  ? hci_enhanced_setup_sync+0x91b/0xa60  hci_enhanced_setup_sync+0x91b/0xa60  ? __pfx_hci_enhanced_setup_sync+0x10/0x10  ? __pfx___mutex_lock+0x10/0x10  hci_cmd_sync_work+0x1c2/0x330  process_one_work+0x7d9/0x1360  ? __pfx_lock_acquire+0x10/0x10  ? __pfx_process_one_work+0x10/0x10  ? assign_work+0x167/0x240  worker_thread+0x5b7/0xf60  ? __kthread_parkme+0xac/0x1c0  ? __pfx_worker_thread+0x10/0x10  ? __pfx_worker_thread+0x10/0x10  kthread+0x293/0x360  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2f/0x70  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  </TASK>  Allocated by task 34:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0x8f/0xa0  __hci_conn_add+0x187/0x17d0  hci_connect_sco+0x2e1/0xb90  sco_sock_connect+0x2a2/0xb80  __sys_connect+0x227/0x2a0  __x64_sys_connect+0x6d/0xb0  do_syscall_64+0x71/0x140  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 37:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3b/0x60  __kasan_slab_free+0x101/0x160  kfree+0xd0/0x250  device_release+0x9a/0x210  kobject_put+0x151/0x280  hci_conn_del+0x448/0xbf0  hci_abort_conn_sync+0x46f/0x980  hci_cmd_sync_work+0x1c2/0x330  process_one_work+0x7d9/0x1360  worker_thread+0x5b7/0xf60  kthread+0x293/0x360  ret_from_fork+0x2f/0x70  ret_from_fork_asm+0x1a/0x30(CVE-2024-50029)\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:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.(CVE-2024-50036)\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 ("igb: Fix igb_down hung on surprise removal") 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]  <TASK> [  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]  </TASK>  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:  i40e: Fix macvlan leak by synchronizing access to mac_filter_hash  This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks.  To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access.  Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future.  Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting  portvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the  mac_filter_hash.  This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.(CVE-2024-50041)\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]  <TASK>     [  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's always going to be a synchronous operation.(CVE-2024-50047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  driver core: bus: Fix double free in driver API bus_register()  For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.(CVE-2024-50055)\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 "uart_port_dtr_rts(uport, false);" 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 &sndev->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->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'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's no state to maintain here as overflows always prune from head-of-list, hence it'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'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's return value 1 will be used as the return value for prog1'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:  mm/mremap: fix move_normal_pmd/retract_page_tables race  In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved.  At that point, the mmap_lock is held in write mode, but no rmap locks are held yet.  For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd().  move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination.  The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it.  So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap:  process A                      process B =========                      ========= mremap   mremap_to     move_vma       move_page_tables         get_old_pmd         alloc_new_pmd                       *** PREEMPT ***                                madvise(MADV_COLLAPSE)                                  do_madvise                                    madvise_walk_vmas                                      madvise_vma_behavior                                        madvise_collapse                                          hpage_collapse_scan_file                                            collapse_file                                              retract_page_tables                                                i_mmap_lock_read(mapping)                                                pmdp_collapse_flush                                                i_mmap_unlock_read(mapping)         move_pgt_entry(NORMAL_PMD, ...)           take_rmap_locks           move_normal_pmd           drop_rmap_locks  When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`.  The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation.  Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken.  Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check.  Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks.  File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug.  As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that.  Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.(CVE-2024-50066)\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'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 <stdio.h> \\#include <stdlib.h> \\#include <string.h>  // 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 < n; ++i)     {         char c = i % 26 + 'a';         str[i] = c;     }     str[n-1] = '\\0'; }  void print_string(char *str) {     printf("%s\\n", 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 "p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring"  > uprobe_events echo 1 > events/uprobes/enable echo 1 > 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:  <TASK>  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  </TASK>  This commit enforces the buffer'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:  pinctrl: stm32: check devm_kasprintf() returned value  devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value.  Found by code review.(CVE-2024-50070)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/bugs: Use code segment selector for VERW operand  Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call:    general protection fault: 0000 [#1] PREEMPT SMP   CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1   Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010   EIP: restore_all_switch_stack+0xbe/0xcf   EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000   ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc   DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046   CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0   Call Trace:    show_regs+0x70/0x78    die_addr+0x29/0x70    exc_general_protection+0x13c/0x348    exc_bounds+0x98/0x98    handle_exception+0x14d/0x14d    exc_bounds+0x98/0x98    restore_all_switch_stack+0xbe/0xcf    exc_bounds+0x98/0x98    restore_all_switch_stack+0xbe/0xcf  This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction:    #GP(0) - If a memory operand effective address is outside the CS, DS, ES,     FS, or GS segment limit.  CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds.  [ mingo: Fixed the SOB chain. ](CVE-2024-50072)\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:  vt: prevent kernel-infoleak in con_font_get()  font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.(CVE-2024-50076)\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 <0f> 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:    <IRQ>    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    </IRQ>    <TASK>    __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)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()  Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it.   unreferenced object 0xffffff80ca58b700 (size 192):    comm "kunit_try_catch", pid 1215, jiffies 4294898264    hex dump (first 32 bytes):      00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00  ..z.........d...      00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff  ................    backtrace (crc 9c09c3fe):      [<0000000052a0be73>] kmemleak_alloc+0x34/0x40      [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4      [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4      [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0      [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac      [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec      [<00000000c5d82c9a>] kthread+0x2e8/0x374      [<00000000f4287308>] ret_from_fork+0x10/0x20  unreferenced object 0xffffff80cc0b0400 (size 64):    comm "kunit_try_catch", pid 1215, jiffies 4294898265    hex dump (first 32 bytes):      80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff  ..........X.....      39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff  9...............    backtrace (crc daf014e9):      [<0000000052a0be73>] kmemleak_alloc+0x34/0x40      [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4      [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528      [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0      [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac      [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec      [<00000000c5d82c9a>] kthread+0x2e8/0x374      [<00000000f4287308>] ret_from_fork+0x10/0x20  unreferenced object 0xffffff80cc0b0700 (size 64):    comm "kunit_try_catch", pid 1215, jiffies 4294898265    hex dump (first 32 bytes):      80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff  ........(.X.....      3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff  <......../......    backtrace (crc 8d877792):      [<0000000052a0be73>] kmemleak_alloc+0x34/0x40      [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4      [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c      [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0      [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac      [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec      [<00000000c5d82c9a>] kthread+0x2e8/0x374      [<00000000f4287308>] ret_from_fork+0x10/0x20  unreferenced object 0xffffff80cc0b0900 (size 64):    comm "kunit_try_catch", pid 1215, jiffies 4294898266    hex dump (first 32 bytes):      80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff  ................      7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00  }...............    backtrace (crc 34181e56):      [<0000000052a0be73>] kmemleak_alloc+0x34/0x40      [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4      [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528      [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8      [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0      [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac      [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec      [<00000000c5d82c9a>] kthread+0x2e8/0x374      [<00000000f4287308>] ret_from_fork+0x10/0x20  unreferenced object 0xffffff80cc0b0980 (size 64):    comm "kunit_try_catch", pid 1215, jiffies 4294898266    hex dump (first 32 bytes):      18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff  ..X.............      67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff  g.........t.....    backtrace (crc 275fd9be):      [<0000000052a0be73>] kmemleak_alloc+0x34/0x40      [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4      [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528      [<000000001396a1a2>] test_add_de ---truncated---(CVE-2024-50084)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix uninitialized pointer free on read_alloc_one_name() error  The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer.  Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it.  This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 ("btrfs: use struct qstr instead of name and namelen pairs").(CVE-2024-50087)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix uninitialized pointer free in add_inode_ref()  The add_inode_ref() function does not initialize the "name" struct when it is declared.  If any of the following calls to "read_one_inode() returns NULL,   dir = read_one_inode(root, parent_objectid);  if (!dir) {   ret = -ENOENT;   goto out;  }   inode = read_one_inode(root, inode_objectid);  if (!inode) {   ret = -EIO;   goto out;  }  then "name.name" would be freed on "out" before being initialized.  out:  ...  kfree(name.name);  This issue was reported by Coverity with CID 1526744.(CVE-2024-50088)","modified":"2026-03-11T07:00:59.764644Z","published":"2024-11-08T01:39:40Z","upstream":["CVE-2024-42122","CVE-2024-44943","CVE-2024-44951","CVE-2024-45021","CVE-2024-46685","CVE-2024-46702","CVE-2024-46735","CVE-2024-46743","CVE-2024-46809","CVE-2024-46815","CVE-2024-46824","CVE-2024-46831","CVE-2024-47679","CVE-2024-47686","CVE-2024-47688","CVE-2024-47690","CVE-2024-47691","CVE-2024-47696","CVE-2024-47699","CVE-2024-47700","CVE-2024-47701","CVE-2024-47703","CVE-2024-47704","CVE-2024-47705","CVE-2024-47719","CVE-2024-47727","CVE-2024-47739","CVE-2024-47742","CVE-2024-47744","CVE-2024-47748","CVE-2024-47751","CVE-2024-47752","CVE-2024-47753","CVE-2024-47756","CVE-2024-49850","CVE-2024-49852","CVE-2024-49858","CVE-2024-49859","CVE-2024-49860","CVE-2024-49862","CVE-2024-49870","CVE-2024-49871","CVE-2024-49874","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-49892","CVE-2024-49896","CVE-2024-49898","CVE-2024-49901","CVE-2024-49909","CVE-2024-49912","CVE-2024-49913","CVE-2024-49917","CVE-2024-49922","CVE-2024-49924","CVE-2024-49931","CVE-2024-49933","CVE-2024-49934","CVE-2024-49936","CVE-2024-49937","CVE-2024-49940","CVE-2024-49954","CVE-2024-49955","CVE-2024-49958","CVE-2024-49960","CVE-2024-49961","CVE-2024-49966","CVE-2024-49967","CVE-2024-49968","CVE-2024-49973","CVE-2024-49975","CVE-2024-49978","CVE-2024-49981","CVE-2024-49983","CVE-2024-49989","CVE-2024-49992","CVE-2024-49994","CVE-2024-49995","CVE-2024-49996","CVE-2024-50000","CVE-2024-50003","CVE-2024-50006","CVE-2024-50008","CVE-2024-50009","CVE-2024-50013","CVE-2024-50014","CVE-2024-50015","CVE-2024-50016","CVE-2024-50019","CVE-2024-50022","CVE-2024-50025","CVE-2024-50026","CVE-2024-50028","CVE-2024-50029","CVE-2024-50033","CVE-2024-50036","CVE-2024-50040","CVE-2024-50041","CVE-2024-50047","CVE-2024-50055","CVE-2024-50058","CVE-2024-50059","CVE-2024-50060","CVE-2024-50063","CVE-2024-50064","CVE-2024-50066","CVE-2024-50067","CVE-2024-50070","CVE-2024-50072","CVE-2024-50074","CVE-2024-50076","CVE-2024-50083","CVE-2024-50084","CVE-2024-50087","CVE-2024-50088"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2367"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42122"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44943"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44951"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46685"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46735"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46743"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46809"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46815"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46824"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46831"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47679"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47686"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47688"},{"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-47696"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47699"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47700"},{"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-47704"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47705"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47719"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47727"},{"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-47744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47751"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47753"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47756"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49850"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49852"},{"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-49870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49871"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49874"},{"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-49892"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49896"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49909"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49912"},{"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-49931"},{"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-49937"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49940"},{"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-49960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49967"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49968"},{"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-49983"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49989"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49994"},{"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-50000"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50003"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50006"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50008"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50009"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50013"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50014"},{"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-50019"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50022"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50026"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50029"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50036"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50040"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50041"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50055"},{"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-50066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50070"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50083"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50088"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-50.0.0.55.oe2403"}]}],"ecosystem_specific":{"src":["kernel-6.6.0-50.0.0.55.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-50.0.0.55.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-devel-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-headers-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-source-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-tools-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-50.0.0.55.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-50.0.0.55.oe2403.x86_64.rpm","perf-6.6.0-50.0.0.55.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-50.0.0.55.oe2403.x86_64.rpm","python3-perf-6.6.0-50.0.0.55.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-50.0.0.55.oe2403.x86_64.rpm"],"aarch64":["bpftool-6.6.0-50.0.0.55.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-devel-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-headers-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-source-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-tools-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-50.0.0.55.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-50.0.0.55.oe2403.aarch64.rpm","perf-6.6.0-50.0.0.55.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-50.0.0.55.oe2403.aarch64.rpm","python3-perf-6.6.0-50.0.0.55.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-50.0.0.55.oe2403.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2024-2367.json"}}],"schema_version":"1.7.5"}