Vulnerabilidades

*** Pendiente de traducción *** The CleverControl employee monitoring software (v11.5.1041.6) fails to validate TLS server certificates during the installation process. The installer downloads and executes external components using curl.exe --insecure, enabling a man-in-the-middle attacker to deliver malicious files that are executed with SYSTEM privileges. This can lead to full remote code execution with administrative rights. No patch is available as the vendor has been unresponsive. It is assumed that previous versions are also affected, but this is not confirmed.

*** Pendiente de traducción *** The SureForms WordPress plugin before 1.9.1 does not sanitise and escape some parameters when outputing them in the page, which could allow admin and above users to perform Cross-Site Scripting attacks.

*** Pendiente de traducción *** 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()).

*** Pendiente de traducción *** 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/

*** Pendiente de traducción *** 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;.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory<br /> <br /> When I did memory failure tests, below panic occurs:<br /> <br /> page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))<br /> kernel BUG at include/linux/page-flags.h:616!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40<br /> RIP: 0010:unpoison_memory+0x2f3/0x590<br /> RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246<br /> RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8<br /> RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0<br /> RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb<br /> R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000<br /> R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe<br /> FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> unpoison_memory+0x2f3/0x590<br /> simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110<br /> debugfs_attr_write+0x42/0x60<br /> full_proxy_write+0x5b/0x80<br /> vfs_write+0xd5/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xb9/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f08f0314887<br /> RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887<br /> RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001<br /> RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009<br /> R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00<br /> <br /> Modules linked in: hwpoison_inject<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:unpoison_memory+0x2f3/0x590<br /> RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246<br /> RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8<br /> RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0<br /> RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb<br /> R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000<br /> R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe<br /> FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)<br /> ---[ end Kernel panic - not syncing: Fatal exception ]---<br /> <br /> The root cause is that unpoison_memory() tries to check the PG_HWPoison<br /> flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is<br /> triggered. This can be reproduced by below steps:<br /> <br /> 1.Offline memory block:<br /> <br /> echo offline &gt; /sys/devices/system/memory/memory12/state<br /> <br /> 2.Get offlined memory pfn:<br /> <br /> page-types -b n -rlN<br /> <br /> 3.Write pfn to unpoison-pfn<br /> <br /> echo &gt; /sys/kernel/debug/hwpoison/unpoison-pfn<br /> <br /> This scenario can be identified by pfn_to_online_page() returning NULL. <br /> And ZONE_DEVICE pages are never expected, so we can simply fail if<br /> pfn_to_online_page() == NULL to fix the bug.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.