Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix recursive semaphore deadlock in fiemap call<br /> <br /> syzbot detected a OCFS2 hang due to a recursive semaphore on a<br /> FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.<br /> <br /> context_switch kernel/sched/core.c:5357 [inline]<br /> __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961<br /> __schedule_loop kernel/sched/core.c:7043 [inline]<br /> schedule+0x165/0x360 kernel/sched/core.c:7058<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115<br /> rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185<br /> __down_write_common kernel/locking/rwsem.c:1317 [inline]<br /> __down_write kernel/locking/rwsem.c:1326 [inline]<br /> down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591<br /> ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142<br /> do_page_mkwrite+0x14d/0x310 mm/memory.c:3361<br /> wp_page_shared mm/memory.c:3762 [inline]<br /> do_wp_page+0x268d/0x5800 mm/memory.c:3981<br /> handle_pte_fault mm/memory.c:6068 [inline]<br /> __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195<br /> handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364<br /> do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387<br /> handle_page_fault arch/x86/mm/fault.c:1476 [inline]<br /> exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532<br /> asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623<br /> RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]<br /> RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]<br /> RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]<br /> RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26<br /> Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89<br /> f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f<br /> 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41<br /> RSP: 0018:ffffc9000403f950 EFLAGS: 00050256<br /> RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038<br /> RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060<br /> RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42<br /> R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098<br /> R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060<br /> copy_to_user include/linux/uaccess.h:225 [inline]<br /> fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145<br /> ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806<br /> ioctl_fiemap fs/ioctl.c:220 [inline]<br /> do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532<br /> __do_sys_ioctl fs/ioctl.c:596 [inline]<br /> __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5f13850fd9<br /> RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9<br /> RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004<br /> RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0<br /> R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b<br /> <br /> ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since<br /> v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the<br /> extent list of this running mmap executable. The user supplied buffer to<br /> hold the fiemap information page faults calling ocfs2_page_mkwrite() which<br /> will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same<br /> semaphore. This recursive semaphore will hold filesystem locks and causes<br /> a hang of the fileystem.<br /> <br /> The ip_alloc_sem protects the inode extent list and size. Release the<br /> read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()<br /> and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock<br /> on the last extent but simplifies the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Fix null-ptr-deref in bitmap_parselist()<br /> <br /> A crash was observed with the following output:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 92 Comm: osnoise_cpus Not tainted 6.17.0-rc4-00201-gd69eb204c255 #138 PREEMPT(voluntary)<br /> RIP: 0010:bitmap_parselist+0x53/0x3e0<br /> Call Trace:<br /> <br /> osnoise_cpus_write+0x7a/0x190<br /> vfs_write+0xf8/0x410<br /> ? do_sys_openat2+0x88/0xd0<br /> ksys_write+0x60/0xd0<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> This issue can be reproduced by below code:<br /> <br /> fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY);<br /> write(fd, "0-2", 0);<br /> <br /> When user pass &amp;#39;count=0&amp;#39; to osnoise_cpus_write(), kmalloc() will return<br /> ZERO_SIZE_PTR (16) and cpulist_parse() treat it as a normal value, which<br /> trigger the null pointer dereference. Add check for the parameter &amp;#39;count&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: Block access to folio overlimit<br /> <br /> syz reported a slab-out-of-bounds Write in fuse_dev_do_write.<br /> <br /> When the number of bytes to be retrieved is truncated to the upper limit<br /> by fc-&gt;max_pages and there is an offset, the oob is triggered.<br /> <br /> Add a loop termination condition to prevent overruns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()<br /> <br /> Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can<br /> cause various locking issues; see the following stack trace (edited for<br /> style) as one example:<br /> <br /> ...<br /> [10.011566] do_raw_spin_lock.cold<br /> [10.011570] try_to_wake_up (5) double-acquiring the same<br /> [10.011575] kick_pool rq_lock, causing a hardlockup<br /> [10.011579] __queue_work<br /> [10.011582] queue_work_on<br /> [10.011585] kernfs_notify<br /> [10.011589] cgroup_file_notify<br /> [10.011593] try_charge_memcg (4) memcg accounting raises an<br /> [10.011597] obj_cgroup_charge_pages MEMCG_MAX event<br /> [10.011599] obj_cgroup_charge_account<br /> [10.011600] __memcg_slab_post_alloc_hook<br /> [10.011603] __kmalloc_node_noprof<br /> ...<br /> [10.011611] bpf_map_kmalloc_node<br /> [10.011612] __bpf_async_init<br /> [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()<br /> [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable<br /> [10.011619] bpf__sched_ext_ops_runnable<br /> [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held<br /> [10.011622] enqueue_task<br /> [10.011626] ttwu_do_activate<br /> [10.011629] sched_ttwu_pending (1) grabs rq_lock<br /> ...<br /> <br /> The above was reproduced on bpf-next (b338cf849ec8) by modifying<br /> ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during<br /> ops.runnable(), and hacking the memcg accounting code a bit to make<br /> a bpf_timer_init() call more likely to raise an MEMCG_MAX event.<br /> <br /> We have also run into other similar variants (both internally and on<br /> bpf-next), including double-acquiring cgroup_file_kn_lock, the same<br /> worker_pool::lock, etc.<br /> <br /> As suggested by Shakeel, fix this by using __GFP_HIGH instead of<br /> GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()<br /> raises an MEMCG_MAX event, we call __memcg_memory_event() with<br /> @allow_spinning=false and avoid calling cgroup_file_notify() there.<br /> <br /> Depends on mm patch<br /> "memcg: skip cgroup_file_notify if spinning is not allowed":<br /> https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/<br /> <br /> v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/<br /> https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/<br /> v1 approach:<br /> https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix subvolume deletion lockup caused by inodes xarray race<br /> <br /> There is a race condition between inode eviction and inode caching that<br /> can cause a live struct btrfs_inode to be missing from the root-&gt;inodes<br /> xarray. Specifically, there is a window during evict() between the inode<br /> being unhashed and deleted from the xarray. If btrfs_iget() is called<br /> for the same inode in that window, it will be recreated and inserted<br /> into the xarray, but then eviction will delete the new entry, leaving<br /> nothing in the xarray:<br /> <br /> Thread 1 Thread 2<br /> ---------------------------------------------------------------<br /> evict()<br /> remove_inode_hash()<br /> btrfs_iget_path()<br /> btrfs_iget_locked()<br /> btrfs_read_locked_inode()<br /> btrfs_add_inode_to_root()<br /> destroy_inode()<br /> btrfs_destroy_inode()<br /> btrfs_del_inode_from_root()<br /> __xa_erase<br /> <br /> In turn, this can cause issues for subvolume deletion. Specifically, if<br /> an inode is in this lost state, and all other inodes are evicted, then<br /> btrfs_del_inode_from_root() will call btrfs_add_dead_root() prematurely.<br /> If the lost inode has a delayed_node attached to it, then when<br /> btrfs_clean_one_deleted_snapshot() calls btrfs_kill_all_delayed_nodes(),<br /> it will loop forever because the delayed_nodes xarray will never become<br /> empty (unless memory pressure forces the inode out). We saw this<br /> manifest as soft lockups in production.<br /> <br /> Fix it by only deleting the xarray entry if it matches the given inode<br /> (using __xa_cmpxchg()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()<br /> <br /> The function of_phy_find_device may return NULL, so we need to take<br /> care before dereferencing phy_dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: fix use-after-free in state_show()<br /> <br /> state_show() reads kdamond-&gt;damon_ctx without holding damon_sysfs_lock. <br /> This allows a use-after-free race:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> state_show() damon_sysfs_turn_damon_on()<br /> ctx = kdamond-&gt;damon_ctx; mutex_lock(&amp;damon_sysfs_lock);<br /> damon_destroy_ctx(kdamond-&gt;damon_ctx);<br /> kdamond-&gt;damon_ctx = NULL;<br /> mutex_unlock(&amp;damon_sysfs_lock);<br /> damon_is_running(ctx); /* ctx is freed */<br /> mutex_lock(&amp;ctx-&gt;kdamond_lock); /* UAF */<br /> <br /> (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and<br /> damon_sysfs_kdamond_release(), which free or replace the context under<br /> damon_sysfs_lock.)<br /> <br /> Fix by taking damon_sysfs_lock before dereferencing the context, mirroring<br /> the locking used in pid_show().<br /> <br /> The bug has existed since state_show() first accessed kdamond-&gt;damon_ctx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix invalid accesses to ceph_connection_v1_info<br /> <br /> There is a place where generic code in messenger.c is reading and<br /> another place where it is writing to con-&gt;v1 union member without<br /> checking that the union member is active (i.e. msgr1 is in use).<br /> <br /> On 64-bit systems, con-&gt;v1.auth_retry overlaps with con-&gt;v2.out_iter,<br /> so such a read is almost guaranteed to return a bogus value instead of<br /> 0 when msgr2 is in use. This ends up being fairly benign because the<br /> side effect is just the invalidation of the authorizer and successive<br /> fetching of new tickets.<br /> <br /> con-&gt;v1.connect_seq overlaps with con-&gt;v2.conn_bufs and the fact that<br /> it&amp;#39;s being written to can cause more serious consequences, but luckily<br /> it&amp;#39;s not something that happens often.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: Fix UAF in polling when open file is released<br /> <br /> A use-after-free (UAF) vulnerability was identified in the PSI (Pressure<br /> Stall Information) monitoring mechanism:<br /> <br /> BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140<br /> Read of size 8 at addr ffff3de3d50bd308 by task systemd/1<br /> <br /> psi_trigger_poll+0x3c/0x140<br /> cgroup_pressure_poll+0x70/0xa0<br /> cgroup_file_poll+0x8c/0x100<br /> kernfs_fop_poll+0x11c/0x1c0<br /> ep_item_poll.isra.0+0x188/0x2c0<br /> <br /> Allocated by task 1:<br /> cgroup_file_open+0x88/0x388<br /> kernfs_fop_open+0x73c/0xaf0<br /> do_dentry_open+0x5fc/0x1200<br /> vfs_open+0xa0/0x3f0<br /> do_open+0x7e8/0xd08<br /> path_openat+0x2fc/0x6b0<br /> do_filp_open+0x174/0x368<br /> <br /> Freed by task 8462:<br /> cgroup_file_release+0x130/0x1f8<br /> kernfs_drain_open_files+0x17c/0x440<br /> kernfs_drain+0x2dc/0x360<br /> kernfs_show+0x1b8/0x288<br /> cgroup_file_show+0x150/0x268<br /> cgroup_pressure_write+0x1dc/0x340<br /> cgroup_file_write+0x274/0x548<br /> <br /> Reproduction Steps:<br /> 1. Open test/cpu.pressure and establish epoll monitoring<br /> 2. Disable monitoring: echo 0 &gt; test/cgroup.pressure<br /> 3. Re-enable monitoring: echo 1 &gt; test/cgroup.pressure<br /> <br /> The race condition occurs because:<br /> 1. When cgroup.pressure is disabled (echo 0 &gt; cgroup.pressure), it:<br /> - Releases PSI triggers via cgroup_file_release()<br /> - Frees of-&gt;priv through kernfs_drain_open_files()<br /> 2. While epoll still holds reference to the file and continues polling<br /> 3. Re-enabling (echo 1 &gt; cgroup.pressure) accesses freed of-&gt;priv<br /> <br /> epolling disable/enable cgroup.pressure<br /> fd=open(cpu.pressure)<br /> while(1)<br /> ...<br /> epoll_wait<br /> kernfs_fop_poll<br /> kernfs_get_active = true echo 0 &gt; cgroup.pressure<br /> ... cgroup_file_show<br /> kernfs_show<br /> // inactive kn<br /> kernfs_drain_open_files<br /> cft-&gt;release(of);<br /> kfree(ctx);<br /> ...<br /> kernfs_get_active = false<br /> echo 1 &gt; cgroup.pressure<br /> kernfs_show<br /> kernfs_activate_one(kn);<br /> kernfs_fop_poll<br /> kernfs_get_active = true<br /> cgroup_file_poll<br /> psi_trigger_poll<br /> // UAF<br /> ...<br /> end: close(fd)<br /> <br /> To address this issue, introduce kernfs_get_active_of() for kernfs open<br /> files to obtain active references. This function will fail if the open file<br /> has been released. Replace kernfs_get_active() with kernfs_get_active_of()<br /> to prevent further operations on released file descriptors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error<br /> <br /> The function move_dirty_folio_in_page_array() was created by commit<br /> ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") by<br /> moving code from ceph_writepages_start() to this function.<br /> <br /> This new function is supposed to return an error code which is checked<br /> by the caller (now ceph_process_folio_batch()), and on error, the<br /> caller invokes redirty_page_for_writepage() and then breaks from the<br /> loop.<br /> <br /> However, the refactoring commit has gone wrong, and it by accident, it<br /> always returns 0 (= success) because it first NULLs the pointer and<br /> then returns PTR_ERR(NULL) which is always 0. This means errors are<br /> silently ignored, leaving NULL entries in the page array, which may<br /> later crash the kernel.<br /> <br /> The simple solution is to call PTR_ERR() before clearing the pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: fix potential OF node use-after-free<br /> <br /> The for_each_child_of_node() helper drops the reference it takes to each<br /> node as it iterates over children and an explicit of_node_put() is only<br /> needed when exiting the loop early.<br /> <br /> Drop the recently introduced bogus additional reference count decrement<br /> at each iteration that could potentially lead to a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: always call ceph_shift_unused_folios_left()<br /> <br /> The function ceph_process_folio_batch() sets folio_batch entries to<br /> NULL, which is an illegal state. Before folio_batch_release() crashes<br /> due to this API violation, the function ceph_shift_unused_folios_left()<br /> is supposed to remove those NULLs from the array.<br /> <br /> However, since commit ce80b76dd327 ("ceph: introduce<br /> ceph_process_folio_batch() method"), this shifting doesn&amp;#39;t happen<br /> anymore because the "for" loop got moved to ceph_process_folio_batch(),<br /> and now the `i` variable that remains in ceph_writepages_start()<br /> doesn&amp;#39;t get incremented anymore, making the shifting effectively<br /> unreachable much of the time.<br /> <br /> Later, commit 1551ec61dc55 ("ceph: introduce ceph_submit_write()<br /> method") added more preconditions for doing the shift, replacing the<br /> `i` check (with something that is still just as broken):<br /> <br /> - if ceph_process_folio_batch() fails, shifting never happens<br /> <br /> - if ceph_move_dirty_page_in_page_array() was never called (because<br /> ceph_process_folio_batch() has returned early for some of various<br /> reasons), shifting never happens<br /> <br /> - if `processed_in_fbatch` is zero (because ceph_process_folio_batch()<br /> has returned early for some of the reasons mentioned above or<br /> because ceph_move_dirty_page_in_page_array() has failed), shifting<br /> never happens<br /> <br /> Since those two commits, any problem in ceph_process_folio_batch()<br /> could crash the kernel, e.g. this way:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000034<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0002 [#1] SMP NOPTI<br /> CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE<br /> Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023<br /> Workqueue: writeback wb_workfn (flush-ceph-1)<br /> RIP: 0010:folios_put_refs+0x85/0x140<br /> Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 &gt;<br /> RSP: 0018:ffffb880af8db778 EFLAGS: 00010207<br /> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003<br /> RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0<br /> RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f<br /> R10: 0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000<br /> FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ceph_writepages_start+0xeb9/0x1410<br /> <br /> The crash can be reproduced easily by changing the<br /> ceph_check_page_before_write() return value to `-E2BIG`.<br /> <br /> (Interestingly, the crash happens only if `huge_zero_folio` has<br /> already been allocated; without `huge_zero_folio`,<br /> is_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL<br /> entries instead of dereferencing them. That makes reproducing the bug<br /> somewhat unreliable. See<br /> https://lore.kernel.org/20250826231626.218675-1-max.kellermann@ionos.com<br /> for a discussion of this detail.)<br /> <br /> My suggestion is to move the ceph_shift_unused_folios_left() to right<br /> after ceph_process_folio_batch() to ensure it always gets called to<br /> fix up the illegal folio_batch state.