Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hibmcge: fix rtnl deadlock issue<br /> <br /> Currently, the hibmcge netdev acquires the rtnl_lock in<br /> pci_error_handlers.reset_prepare() and releases it in<br /> pci_error_handlers.reset_done().<br /> <br /> However, in the PCI framework:<br /> pci_reset_bus - __pci_reset_slot - pci_slot_save_and_disable_locked -<br /> pci_dev_save_and_disable - err_handler-&gt;reset_prepare(dev);<br /> <br /> In pci_slot_save_and_disable_locked():<br /> list_for_each_entry(dev, &amp;slot-&gt;bus-&gt;devices, bus_list) {<br /> if (!dev-&gt;slot || dev-&gt;slot!= slot)<br /> continue;<br /> pci_dev_save_and_disable(dev);<br /> if (dev-&gt;subordinate)<br /> pci_bus_save_and_disable_locked(dev-&gt;subordinate);<br /> }<br /> <br /> This will iterate through all devices under the current bus and execute<br /> err_handler-&gt;reset_prepare(), causing two devices of the hibmcge driver<br /> to sequentially request the rtnl_lock, leading to a deadlock.<br /> <br /> Since the driver now executes netif_device_detach()<br /> before the reset process, it will not concurrently with<br /> other netdev APIs, so there is no need to hold the rtnl_lock now.<br /> <br /> Therefore, this patch removes the rtnl_lock during the reset process and<br /> adjusts the position of HBG_NIC_STATE_RESETTING to ensure<br /> that multiple resets are not executed concurrently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: fix refcount leak on table dump<br /> <br /> There is a reference count leak in ctnetlink_dump_table():<br /> if (res ct_general); // HERE<br /> cb-&gt;args[1] = (unsigned long)ct;<br /> ...<br /> <br /> While its very unlikely, its possible that ct == last.<br /> If this happens, then the refcount of ct was already incremented.<br /> This 2nd increment is never undone.<br /> <br /> This prevents the conntrack object from being released, which in turn<br /> keeps prevents cnet-&gt;count from dropping back to 0.<br /> <br /> This will then block the netns dismantle (or conntrack rmmod) as<br /> nf_conntrack_cleanup_net_list() will wait forever.<br /> <br /> This can be reproduced by running conntrack_resize.sh selftest in a loop.<br /> It takes ~20 minutes for me on a preemptible kernel on average before<br /> I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.<br /> <br /> One fix would to change this to:<br /> if (res ct_general);<br /> <br /> But this reference counting isn&amp;#39;t needed in the first place.<br /> We can just store a cookie value instead.<br /> <br /> A followup patch will do the same for ctnetlink_exp_dump_table,<br /> it looks to me as if this has the same problem and like<br /> ctnetlink_dump_table, we only need a &amp;#39;skip hint&amp;#39;, not the actual<br /> object so we can apply the same cookie strategy there as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> habanalabs: fix UAF in export_dmabuf()<br /> <br /> As soon as we&amp;#39;d inserted a file reference into descriptor table, another<br /> thread could close it. That&amp;#39;s fine for the case when all we are doing is<br /> returning that descriptor to userland (it&amp;#39;s a race, but it&amp;#39;s a userland<br /> race and there&amp;#39;s nothing the kernel can do about it). However, if we<br /> follow fd_install() with any kind of access to objects that would be<br /> destroyed on close (be it the struct file itself or anything destroyed<br /> by its -&gt;release()), we have a UAF.<br /> <br /> dma_buf_fd() is a combination of reserving a descriptor and fd_install().<br /> habanalabs export_dmabuf() calls it and then proceeds to access the<br /> objects destroyed on close. In particular, it grabs an extra reference to<br /> another struct file that will be dropped as part of -&gt;release() for ours;<br /> that "will be" is actually "might have already been".<br /> <br /> Fix that by reserving descriptor before anything else and do fd_install()<br /> only when everything had been set up. As a side benefit, we no longer<br /> have the failure exit with file already created, but reference to<br /> underlying file (as well as -&gt;dmabuf_export_cnt, etc.) not grabbed yet;<br /> unlike dma_buf_fd(), fd_install() can&amp;#39;t fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Validate i_depth for exhash directories<br /> <br /> A fuzzer test introduced corruption that ends up with a depth of 0 in<br /> dir_e_read(), causing an undefined shift by 32 at:<br /> <br /> index = hash &gt;&gt; (32 - dip-&gt;i_depth);<br /> <br /> As calculated in an open-coded way in dir_make_exhash(), the minimum<br /> depth for an exhash directory is ilog2(sdp-&gt;sd_hash_ptrs) and 0 is<br /> invalid as sdp-&gt;sd_hash_ptrs is fixed as sdp-&gt;bsize / 16 at mount time.<br /> <br /> So we can avoid the undefined behaviour by checking for depth values<br /> lower than the minimum in gfs2_dinode_in(). Values greater than the<br /> maximum are already being checked for there.<br /> <br /> Also switch the calculation in dir_make_exhash() to use ilog2() to<br /> clarify how the depth is calculated.<br /> <br /> Tested with the syzkaller repro.c and xfstests &amp;#39;-g quick&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/server: avoid deadlock when linking with ReplaceIfExists<br /> <br /> If smb2_create_link() is called with ReplaceIfExists set and the name<br /> does exist then a deadlock will happen.<br /> <br /> ksmbd_vfs_kern_path_locked() will return with success and the parent<br /> directory will be locked. ksmbd_vfs_remove_file() will then remove the<br /> file. ksmbd_vfs_link() will then be called while the parent is still<br /> locked. It will try to lock the same parent and will deadlock.<br /> <br /> This patch moves the ksmbd_vfs_kern_path_unlock() call to *before*<br /> ksmbd_vfs_link() and then simplifies the code, removing the file_present<br /> flag variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: don&amp;#39;t use BUG_ON() in hfsplus_create_attributes_file()<br /> <br /> When the volume header contains erroneous values that do not reflect<br /> the actual state of the filesystem, hfsplus_fill_super() assumes that<br /> the attributes file is not yet created, which later results in hitting<br /> BUG_ON() when hfsplus_create_attributes_file() is called. Replace this<br /> BUG_ON() with -EIO error with a message to suggest running fsck tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()<br /> <br /> The hfsplus_readdir() method is capable to crash by calling<br /> hfsplus_uni2asc():<br /> <br /> [ 667.121659][ T9805] ==================================================================<br /> [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10<br /> [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805<br /> [ 667.124578][ T9805]<br /> [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)<br /> [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 667.124890][ T9805] Call Trace:<br /> [ 667.124893][ T9805] <br /> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0<br /> [ 667.124911][ T9805] print_report+0xd0/0x660<br /> [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610<br /> [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180<br /> [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10<br /> [ 667.124942][ T9805] kasan_report+0xc6/0x100<br /> [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10<br /> [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10<br /> [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360<br /> [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0<br /> [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10<br /> [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0<br /> [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20<br /> [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0<br /> [ 667.125022][ T9805] ? lock_acquire+0x30/0x80<br /> [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20<br /> [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0<br /> [ 667.125044][ T9805] ? putname+0x154/0x1a0<br /> [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10<br /> [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0<br /> [ 667.125069][ T9805] iterate_dir+0x296/0xb20<br /> [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0<br /> [ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10<br /> [ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200<br /> [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10<br /> [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0<br /> [ 667.125143][ T9805] do_syscall_64+0xc9/0x480<br /> [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9<br /> [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48<br /> [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9<br /> [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9<br /> [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004<br /> [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110<br /> [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260<br /> [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 667.125207][ T9805] <br /> [ 667.125210][ T9805]<br /> [ 667.145632][ T9805] Allocated by task 9805:<br /> [ 667.145991][ T9805] kasan_save_stack+0x20/0x40<br /> [ 667.146352][ T9805] kasan_save_track+0x14/0x30<br /> [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0<br /> [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550<br /> [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0<br /> [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0<br /> [ 667.148174][ T9805] iterate_dir+0x296/0xb20<br /> [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0<br /> [ 667.148937][ T9805] do_syscall_64+0xc9/0x480<br /> [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 667.149809][ T9805]<br /> [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000<br /> [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048<br /> [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of<br /> [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)<br /> [ 667.1<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()<br /> <br /> The hfsplus_bnode_read() method can trigger the issue:<br /> <br /> [ 174.852007][ T9784] ==================================================================<br /> [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360<br /> [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784<br /> [ 174.854059][ T9784]<br /> [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)<br /> [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 174.854286][ T9784] Call Trace:<br /> [ 174.854289][ T9784] <br /> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0<br /> [ 174.854305][ T9784] print_report+0xd0/0x660<br /> [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610<br /> [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180<br /> [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360<br /> [ 174.854337][ T9784] kasan_report+0xc6/0x100<br /> [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360<br /> [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360<br /> [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380<br /> [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10<br /> [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0<br /> [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310<br /> [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40<br /> [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0<br /> [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0<br /> [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10<br /> [ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10<br /> [ 174.854436][ T9784] ? __asan_memset+0x23/0x50<br /> [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320<br /> [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10<br /> [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0<br /> [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40<br /> [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0<br /> [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10<br /> [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0<br /> [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10<br /> [ 174.854525][ T9784] ? down_write+0x148/0x200<br /> [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10<br /> [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0<br /> [ 174.854549][ T9784] do_unlinkat+0x490/0x670<br /> [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10<br /> [ 174.854565][ T9784] ? __might_fault+0xbc/0x130<br /> [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550<br /> [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110<br /> [ 174.854592][ T9784] do_syscall_64+0xc9/0x480<br /> [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167<br /> [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08<br /> [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057<br /> [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167<br /> [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50<br /> [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40<br /> [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0<br /> [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 174.854658][ T9784] <br /> [ 174.854661][ T9784]<br /> [ 174.879281][ T9784] Allocated by task 9784:<br /> [ 174.879664][ T9784] kasan_save_stack+0x20/0x40<br /> [ 174.880082][ T9784] kasan_save_track+0x14/0x30<br /> [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0<br /> [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550<br /> [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890<br /> [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10<br /> [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520<br /> [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix slab-out-of-bounds in hfs_bnode_read()<br /> <br /> This patch introduces is_bnode_offset_valid() method that checks<br /> the requested offset value. Also, it introduces<br /> check_and_correct_requested_length() method that checks and<br /> correct the requested length (if it is necessary). These methods<br /> are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(),<br /> hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent<br /> the access out of allocated memory and triggering the crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Make dma-fences compliant with the safe access rules<br /> <br /> Xe can free some of the data pointed to by the dma-fences it exports. Most<br /> notably the timeline name can get freed if userspace closes the associated<br /> submit queue. At the same time the fence could have been exported to a<br /> third party (for example a sync_fence fd) which will then cause an use-<br /> after-free on subsequent access.<br /> <br /> To make this safe we need to make the driver compliant with the newly<br /> documented dma-fence rules. Driver has to ensure a RCU grace period<br /> between signalling a fence and freeing any data pointed to by said fence.<br /> <br /> For the timeline name we simply make the queue be freed via kfree_rcu and<br /> for the shared lock associated with multiple queues we add a RCU grace<br /> period before freeing the per GT structure holding the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/nocb: Fix possible invalid rdp&amp;#39;s-&gt;nocb_cb_kthread pointer access<br /> <br /> In the preparation stage of CPU online, if the corresponding<br /> the rdp&amp;#39;s-&gt;nocb_cb_kthread does not exist, will be created,<br /> there is a situation where the rdp&amp;#39;s rcuop kthreads creation fails,<br /> and then de-offload this CPU&amp;#39;s rdp, does not assign this CPU&amp;#39;s<br /> rdp-&gt;nocb_cb_kthread pointer, but this rdp&amp;#39;s-&gt;nocb_gp_rdp and<br /> rdp&amp;#39;s-&gt;rdp_gp-&gt;nocb_gp_kthread is still valid.<br /> <br /> This will cause the subsequent re-offload operation of this offline<br /> CPU, which will pass the conditional check and the kthread_unpark()<br /> will access invalid rdp&amp;#39;s-&gt;nocb_cb_kthread pointer.<br /> <br /> This commit therefore use rdp&amp;#39;s-&gt;nocb_gp_kthread instead of<br /> rdp_gp&amp;#39;s-&gt;nocb_gp_kthread for safety check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: fix null pointer access<br /> <br /> Writing a string without delimiters (&amp;#39; &amp;#39;, &amp;#39;\n&amp;#39;, &amp;#39;\0&amp;#39;) to the under<br /> gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile<br /> will result in a null pointer dereference.