Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ctcm: Fix double-kfree<br /> <br /> The function &amp;#39;mpc_rcvd_sweep_req(mpcginfo)&amp;#39; is called conditionally<br /> from function &amp;#39;ctcmpc_unpack_skb&amp;#39;. It frees passed mpcginfo.<br /> After that a call to function &amp;#39;kfree&amp;#39; in function &amp;#39;ctcmpc_unpack_skb&amp;#39;<br /> frees it again.<br /> <br /> Remove &amp;#39;kfree&amp;#39; call in function &amp;#39;mpc_rcvd_sweep_req(mpcginfo)&amp;#39;.<br /> <br /> Bug detected by the clang static analyzer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: rate: Unset parent pointer in devl_rate_nodes_destroy<br /> <br /> The function devl_rate_nodes_destroy is documented to "Unset parent for<br /> all rate objects". However, it was only calling the driver-specific<br /> `rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementing<br /> the parent&amp;#39;s refcount, without actually setting the<br /> `devlink_rate-&gt;parent` pointer to NULL.<br /> <br /> This leaves a dangling pointer in the `devlink_rate` struct, which cause<br /> refcount error in netdevsim[1] and mlx5[2]. In addition, this is<br /> inconsistent with the behavior of `devlink_nl_rate_parent_node_set`,<br /> where the parent pointer is correctly cleared.<br /> <br /> This patch fixes the issue by explicitly setting `devlink_rate-&gt;parent`<br /> to NULL after notifying the driver, thus fulfilling the function&amp;#39;s<br /> documented behavior for all rate objects.<br /> <br /> [1]<br /> repro steps:<br /> echo 1 &gt; /sys/bus/netdevsim/new_device<br /> devlink dev eswitch set netdevsim/netdevsim1 mode switchdev<br /> echo 1 &gt; /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfs<br /> devlink port function rate add netdevsim/netdevsim1/test_node<br /> devlink port function rate set netdevsim/netdevsim1/128 parent test_node<br /> echo 1 &gt; /sys/bus/netdevsim/del_device<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> __nsim_dev_port_del+0x6c/0x70 [netdevsim]<br /> nsim_dev_reload_destroy+0x11c/0x140 [netdevsim]<br /> nsim_drv_remove+0x2b/0xb0 [netdevsim]<br /> device_release_driver_internal+0x194/0x1f0<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x159/0x3c0<br /> device_unregister+0x1a/0x60<br /> del_device_store+0x111/0x170 [netdevsim]<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x55/0x10f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> devlink dev eswitch set pci/0000:08:00.0 mode switchdev<br /> devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000<br /> devlink port function rate add pci/0000:08:00.0/group1<br /> devlink port function rate set pci/0000:08:00.0/32768 parent group1<br /> modprobe -r mlx5_ib mlx5_fwctl mlx5_core<br /> <br /> dmesg:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0<br /> CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0x42/0xe0<br /> Call Trace:<br /> <br /> devl_rate_leaf_destroy+0x8d/0x90<br /> mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core]<br /> mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core]<br /> mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core]<br /> mlx5_sf_esw_event+0xc4/0x120 [mlx5_core]<br /> notifier_call_chain+0x33/0xa0<br /> blocking_notifier_call_chain+0x3b/0x50<br /> mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core]<br /> mlx5_eswitch_disable+0x63/0x90 [mlx5_core]<br /> mlx5_unload+0x1d/0x170 [mlx5_core]<br /> mlx5_uninit_one+0xa2/0x130 [mlx5_core]<br /> remove_one+0x78/0xd0 [mlx5_core]<br /> pci_device_remove+0x39/0xa0<br /> device_release_driver_internal+0x194/0x1f0<br /> unbind_store+0x99/0xa0<br /> kernfs_fop_write_iter+0x12e/0x1e0<br /> vfs_write+0x215/0x3d0<br /> ksys_write+0x5f/0xd0<br /> do_syscall_64+0x53/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: avoid NULL dereference when chunk data buffer is missing<br /> <br /> chunk-&gt;skb pointer is dereferenced in the if-block where it&amp;#39;s supposed<br /> to be NULL only.<br /> <br /> chunk-&gt;skb can only be NULL if chunk-&gt;head_skb is not. Check for frag_list<br /> instead and do it just before replacing chunk-&gt;skb. We&amp;#39;re sure that<br /> otherwise chunk-&gt;skb is non-NULL because of outer if() condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix crafted invalid cases for encoded extents<br /> <br /> Robert recently reported two corrupted images that can cause system<br /> crashes, which are related to the new encoded extents introduced<br /> in Linux 6.15:<br /> <br /> - The first one [1] has plen != 0 (e.g. plen == 0x2000000) but<br /> (plen &amp; Z_EROFS_EXTENT_PLEN_MASK) == 0. It is used to represent<br /> special extents such as sparse extents (!EROFS_MAP_MAPPED), but<br /> previously only plen == 0 was handled;<br /> <br /> - The second one [2] has pa 0xffffffffffdcffed and plen 0xb4000,<br /> then "cur [0xfffffffffffff000] += bvec.bv_len [0x1000]" in<br /> "} while ((cur += bvec.bv_len) compressed_bvecs[] in<br /> z_erofs_submit_queue(). EROFS only supports 48-bit physical block<br /> addresses (up to 1EiB for 4k blocks), so add a sanity check to<br /> enforce this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix unlikely race in gdlm_put_lock<br /> <br /> In gdlm_put_lock(), there is a small window of time in which the<br /> DFL_UNMOUNT flag has been set but the lockspace hasn&amp;#39;t been released,<br /> yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().<br /> To prevent it from dereferencing freed glock objects, only free the<br /> glock if the lockspace has actually been released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix KMSAN uninit-value issue in hfs_find_set_zero_bits()<br /> <br /> The syzbot reported issue in hfs_find_set_zero_bits():<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45<br /> hfs_find_set_zero_bits+0x74d/0xb60 fs/hfs/bitmap.c:45<br /> hfs_vbm_search_free+0x13c/0x5b0 fs/hfs/bitmap.c:151<br /> hfs_extend_file+0x6a5/0x1b00 fs/hfs/extent.c:408<br /> hfs_get_block+0x435/0x1150 fs/hfs/extent.c:353<br /> __block_write_begin_int+0xa76/0x3030 fs/buffer.c:2151<br /> block_write_begin fs/buffer.c:2262 [inline]<br /> cont_write_begin+0x10e1/0x1bc0 fs/buffer.c:2601<br /> hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52<br /> cont_expand_zero fs/buffer.c:2528 [inline]<br /> cont_write_begin+0x35a/0x1bc0 fs/buffer.c:2591<br /> hfs_write_begin+0x85/0x130 fs/hfs/inode.c:52<br /> hfs_file_truncate+0x1d6/0xe60 fs/hfs/extent.c:494<br /> hfs_inode_setattr+0x964/0xaa0 fs/hfs/inode.c:654<br /> notify_change+0x1993/0x1aa0 fs/attr.c:552<br /> do_truncate+0x28f/0x310 fs/open.c:68<br /> do_ftruncate+0x698/0x730 fs/open.c:195<br /> do_sys_ftruncate fs/open.c:210 [inline]<br /> __do_sys_ftruncate fs/open.c:215 [inline]<br /> __se_sys_ftruncate fs/open.c:213 [inline]<br /> __x64_sys_ftruncate+0x11b/0x250 fs/open.c:213<br /> x64_sys_call+0xfe3/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:78<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4154 [inline]<br /> slab_alloc_node mm/slub.c:4197 [inline]<br /> __kmalloc_cache_noprof+0x7f7/0xed0 mm/slub.c:4354<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> hfs_mdb_get+0x1cc8/0x2a90 fs/hfs/mdb.c:175<br /> hfs_fill_super+0x3d0/0xb80 fs/hfs/super.c:337<br /> get_tree_bdev_flags+0x6e3/0x920 fs/super.c:1681<br /> get_tree_bdev+0x38/0x50 fs/super.c:1704<br /> hfs_get_tree+0x35/0x40 fs/hfs/super.c:388<br /> vfs_get_tree+0xb0/0x5c0 fs/super.c:1804<br /> do_new_mount+0x738/0x1610 fs/namespace.c:3902<br /> path_mount+0x6db/0x1e90 fs/namespace.c:4226<br /> do_mount fs/namespace.c:4239 [inline]<br /> __do_sys_mount fs/namespace.c:4450 [inline]<br /> __se_sys_mount+0x6eb/0x7d0 fs/namespace.c:4427<br /> __x64_sys_mount+0xe4/0x150 fs/namespace.c:4427<br /> x64_sys_call+0xfa7/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:166<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 1 UID: 0 PID: 12609 Comm: syz.1.2692 Not tainted 6.16.0-syzkaller #0 PREEMPT(none)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> =====================================================<br /> <br /> The HFS_SB(sb)-&gt;bitmap buffer is allocated in hfs_mdb_get():<br /> <br /> HFS_SB(sb)-&gt;bitmap = kmalloc(8192, GFP_KERNEL);<br /> <br /> Finally, it can trigger the reported issue because kmalloc()<br /> doesn&amp;#39;t clear the allocated memory. If allocated memory contains<br /> only zeros, then everything will work pretty fine.<br /> But if the allocated memory contains the "garbage", then<br /> it can affect the bitmap operations and it triggers<br /> the reported issue.<br /> <br /> This patch simply exchanges the kmalloc() on kzalloc()<br /> with the goal to guarantee the correctness of bitmap operations.<br /> Because, newly created allocation bitmap should have all<br /> available blocks free. Potentially, initialization bitmap&amp;#39;s read<br /> operation could not fill the whole allocated memory and<br /> "garbage" in the not initialized memory will be the reason of<br /> volume coruptions and file system driver bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()<br /> <br /> The syzbot reported issue in __hfsplus_ext_cache_extent():<br /> <br /> [ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990<br /> [ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990<br /> [ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0<br /> [ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0<br /> [ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0<br /> [ 70.196959][ T9350] cont_write_begin+0x1000/0x1950<br /> [ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130<br /> [ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060<br /> [ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460<br /> [ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0<br /> [ 70.199393][ T9350] vfs_write+0xb0f/0x14e0<br /> [ 70.199771][ T9350] ksys_write+0x23e/0x490<br /> [ 70.200149][ T9350] __x64_sys_write+0x97/0xf0<br /> [ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0<br /> [ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0<br /> [ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 70.202054][ T9350]<br /> [ 70.202279][ T9350] Uninit was created at:<br /> [ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80<br /> [ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0<br /> [ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0<br /> [ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0<br /> [ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0<br /> [ 70.205074][ T9350] cont_write_begin+0x1000/0x1950<br /> [ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130<br /> [ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060<br /> [ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460<br /> [ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0<br /> [ 70.207552][ T9350] vfs_write+0xb0f/0x14e0<br /> [ 70.207961][ T9350] ksys_write+0x23e/0x490<br /> [ 70.208375][ T9350] __x64_sys_write+0x97/0xf0<br /> [ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0<br /> [ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0<br /> [ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 70.210230][ T9350]<br /> [ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5<br /> [ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 70.212115][ T9350] =====================================================<br /> [ 70.212734][ T9350] Disabling lock debugging due to kernel taint<br /> [ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ...<br /> [ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5<br /> [ 70.214679][ T9350] Tainted: [B]=BAD_PAGE<br /> [ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 70.215999][ T9350] Call Trace:<br /> [ 70.216309][ T9350] <br /> [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0<br /> [ 70.217025][ T9350] dump_stack+0x1e/0x30<br /> [ 70.217421][ T9350] panic+0x502/0xca0<br /> [ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0<br /> <br /> [ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ...<br /> kernel<br /> :[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0<br /> set ...<br /> [ 70.221254][ T9350] ? __msan_warning+0x96/0x120<br /> [ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990<br /> [ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0<br /> [ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0<br /> [ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0<br /> [ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950<br /> [ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130<br /> [ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060<br /> [ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460<br /> [ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0<br /> [ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0<br /> [ 70.228997][ T9350] ? ksys_write+0x23e/0x490<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nios2: ensure that memblock.current_limit is set when setting pfn limits<br /> <br /> On nios2, with CONFIG_FLATMEM set, the kernel relies on<br /> memblock_get_current_limit() to determine the limits of mem_map, in<br /> particular for max_low_pfn.<br /> Unfortunately, memblock.current_limit is only default initialized to<br /> MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading<br /> to situations where max_low_pfn can erroneously exceed the value of<br /> max_pfn and, thus, the valid range of available DRAM.<br /> <br /> This can in turn cause kernel-level paging failures, e.g.:<br /> <br /> [ 76.900000] Unable to handle kernel paging request at virtual address 20303000<br /> [ 76.900000] ea = c0080890, ra = c000462c, cause = 14<br /> [ 76.900000] Kernel panic - not syncing: Oops<br /> [ 76.900000] ---[ end Kernel panic - not syncing: Oops ]---<br /> <br /> This patch fixes this by pre-calculating memblock.current_limit<br /> based on the upper limits of the available memory ranges via<br /> adjust_lowmem_bounds, a simplified version of the equivalent<br /> implementation within the arm architecture.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix out of bounds memory read error in symlink repair<br /> <br /> xfs/286 produced this report on my test fleet:<br /> <br /> ==================================================================<br /> BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110<br /> <br /> Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184):<br /> memcpy_orig+0x54/0x110<br /> xrep_symlink_salvage_inline+0xb3/0xf0 [xfs]<br /> xrep_symlink_salvage+0x100/0x110 [xfs]<br /> xrep_symlink+0x2e/0x80 [xfs]<br /> xrep_attempt+0x61/0x1f0 [xfs]<br /> xfs_scrub_metadata+0x34f/0x5c0 [xfs]<br /> xfs_ioc_scrubv_metadata+0x387/0x560 [xfs]<br /> xfs_file_ioctl+0xe23/0x10e0 [xfs]<br /> __x64_sys_ioctl+0x76/0xc0<br /> do_syscall_64+0x4e/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128<br /> <br /> allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago):<br /> xfs_init_local_fork+0x79/0xe0 [xfs]<br /> xfs_iformat_local+0xa4/0x170 [xfs]<br /> xfs_iformat_data_fork+0x148/0x180 [xfs]<br /> xfs_inode_from_disk+0x2cd/0x480 [xfs]<br /> xfs_iget+0x450/0xd60 [xfs]<br /> xfs_bulkstat_one_int+0x6b/0x510 [xfs]<br /> xfs_bulkstat_iwalk+0x1e/0x30 [xfs]<br /> xfs_iwalk_ag_recs+0xdf/0x150 [xfs]<br /> xfs_iwalk_run_callbacks+0xb9/0x190 [xfs]<br /> xfs_iwalk_ag+0x1dc/0x2f0 [xfs]<br /> xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs]<br /> xfs_iwalk+0xa4/0xd0 [xfs]<br /> xfs_bulkstat+0xfa/0x170 [xfs]<br /> xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs]<br /> xfs_file_ioctl+0xbf2/0x10e0 [xfs]<br /> __x64_sys_ioctl+0x76/0xc0<br /> do_syscall_64+0x4e/0x1e0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014<br /> ==================================================================<br /> <br /> On further analysis, I realized that the second parameter to min() is<br /> not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data<br /> buffer. if_bytes can be smaller than the data fork size because:<br /> <br /> (a) the forkoff code tries to keep the data area as large as possible<br /> (b) for symbolic links, if_bytes is the ondisk file size + 1<br /> (c) forkoff is always a multiple of 8.<br /> <br /> Case in point: for a single-byte symlink target, forkoff will be<br /> 8 but the buffer will only be 2 bytes long.<br /> <br /> In other words, the logic here is wrong and we walk off the end of the<br /> incore buffer. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/notify: call exportfs_encode_fid with s_umount<br /> <br /> Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while<br /> the overlayfs is being unmounted, can lead to dereferencing NULL ptr.<br /> <br /> This issue was found by syzkaller.<br /> <br /> Race Condition Diagram:<br /> <br /> Thread 1 Thread 2<br /> -------- --------<br /> <br /> generic_shutdown_super()<br /> shrink_dcache_for_umount<br /> sb-&gt;s_root = NULL<br /> <br /> |<br /> | vfs_read()<br /> | inotify_fdinfo()<br /> | * inode get from mark *<br /> | show_mark_fhandle(m, inode)<br /> | exportfs_encode_fid(inode, ..)<br /> | ovl_encode_fh(inode, ..)<br /> | ovl_check_encode_origin(inode)<br /> | * deref i_sb-&gt;s_root *<br /> |<br /> |<br /> v<br /> fsnotify_sb_delete(sb)<br /> <br /> Which then leads to:<br /> <br /> [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)<br /> <br /> <br /> <br /> [ 32.143353] Call Trace:<br /> [ 32.143732] ovl_encode_fh+0xd5/0x170<br /> [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300<br /> [ 32.144425] show_mark_fhandle+0xbe/0x1f0<br /> [ 32.145805] inotify_fdinfo+0x226/0x2d0<br /> [ 32.146442] inotify_show_fdinfo+0x1c5/0x350<br /> [ 32.147168] seq_show+0x530/0x6f0<br /> [ 32.147449] seq_read_iter+0x503/0x12a0<br /> [ 32.148419] seq_read+0x31f/0x410<br /> [ 32.150714] vfs_read+0x1f0/0x9e0<br /> [ 32.152297] ksys_read+0x125/0x240<br /> <br /> IOW ovl_check_encode_origin derefs inode-&gt;i_sb-&gt;s_root, after it was set<br /> to NULL in the unmount path.<br /> <br /> Fix it by protecting calling exportfs_encode_fid() from<br /> show_mark_fhandle() with s_umount lock.<br /> <br /> This form of fix was suggested by Amir in [1].<br /> <br /> [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: alienware-wmi-wmax: Fix NULL pointer dereference in sleep handlers<br /> <br /> Devices without the AWCC interface don&amp;#39;t initialize `awcc`. Add a check<br /> before dereferencing it in sleep handlers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()<br /> <br /> If fs_info-&gt;super_copy or fs_info-&gt;super_for_commit allocated failed in<br /> btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().<br /> Otherwise btrfs_check_leaked_roots() would access NULL pointer because<br /> fs_info-&gt;allocated_roots had not been initialised.<br /> <br /> syzkaller reported the following information:<br /> ------------[ cut here ]------------<br /> BUG: unable to handle page fault for address: fffffffffffffbb0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0<br /> Oops: Oops: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)<br /> RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]<br /> RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]<br /> RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]<br /> RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]<br /> RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230<br /> [...]<br /> Call Trace:<br /> <br /> btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280<br /> btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029<br /> btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097<br /> vfs_get_tree+0x98/0x320 fs/super.c:1759<br /> do_new_mount+0x357/0x660 fs/namespace.c:3899<br /> path_mount+0x716/0x19c0 fs/namespace.c:4226<br /> do_mount fs/namespace.c:4239 [inline]<br /> __do_sys_mount fs/namespace.c:4450 [inline]<br /> __se_sys_mount fs/namespace.c:4427 [inline]<br /> __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f032eaffa8d<br /> [...]