- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
by Pan Taixi 18 Aug '26

18 Aug '26

From: Bryam Vargas <hexlabsecurity(a)proton.me> mainline inclusion from mainline-v7.2-rc5 commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/16967 CVE: CVE-2026-68160 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path. Cc: stable(a)vger.kernel.org Fixes: a8599bd821d0 ("ceph: capability management") Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Conflicts: fs/ceph/caps.c [Context conflicts unmerged commit 8ea412e18131 ("ceph: improve caps debugging output")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- fs/ceph/caps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index b631719941c2..80591f37dd77 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -3765,10 +3765,11 @@ void ceph_handle_caps(struct ceph_mds_session *session, seq = le32_to_cpu(h->seq); mseq = le32_to_cpu(h->migrate_seq); snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); + ceph_decode_need(&snaptrace, end, snaptrace_len, bad); p = snaptrace + snaptrace_len; if (msg_version >= 2) { u32 flock_len; ceph_decode_32_safe(&p, end, flock_len, bad); -- 2.34.1

2 1

[PATCH OLK-6.6] cifs: Fix busy dentry used during umounting
by Zizhi Wo 18 Aug '26

18 Aug '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9783 -------------------------------- Commit 3b11912af75f ("[Backport] cifs: Fix busy dentry used after unmounting") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb to solve it. However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release: process A[dio] process B[cifsd] process C[close] cifs_direct_writev ... smb2_writev_callback wait_for_completion_killable queue_work(cifsiod_wq, xx)[1] cifs_uncached_writev_complete complete(&ctx->done)[2] kref_put(&ctx->refcount, xxx) // write done! cifs_close _cifsFileInfo_put[3] --cfile->count // count = 1 kref_put(&wdata->refcount, xx) ... _cifsFileInfo_put --cfile->count // count = 0 queue_work(fileinfo_put_wq, xx)[4] cifsFileInfo_put_work cifsFileInfo_put_final dput At [1] the work is queued onto cifsiod_wq. At [2] the foreground thread waiting on the write is woken up; after the write path exits and closes the file, at [3] the cfile reference count has not yet dropped to 0, so the final dput is not called synchronously. The cifsiod worker then drops the cfile reference count to 0 and calls the final dput on fileinfo_put_wq at [4]. If the umount path is triggered before [4], it results in the following warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test} still in use (1) [unmount of cifs cifs] Therefore, cifsiod_wq/fileinfo_put_wq/serverclose_wq need to be flushed. Fixes: b28b211c8d8f ("cifs: open files should not hold ref on superblock") Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/smb/client/cifsfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c index a2887b978dc8..f6d74e961414 100644 --- a/fs/smb/client/cifsfs.c +++ b/fs/smb/client/cifsfs.c @@ -298,10 +298,13 @@ static void cifs_kill_sb(struct super_block *sb) /* Wait for all pending oplock breaks to complete */ flush_workqueue(cifsoplockd_wq); /* Wait for all opened files to release */ flush_workqueue(deferredclose_wq); + flush_workqueue(cifsiod_wq); + flush_workqueue(serverclose_wq); + flush_workqueue(fileinfo_put_wq); /* finally release root dentry */ dput(cifs_sb->root); cifs_sb->root = NULL; } -- 2.52.0

1 0

[PATCH OLK-5.10] ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
by Pan Taixi 18 Aug '26

18 Aug '26

From: Bryam Vargas <hexlabsecurity(a)proton.me> mainline inclusion from mainline-v7.2-rc5 commit 4dbc71bcaf9a30abf3920a4e2cc4ed33bba78c02 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/16967 CVE: CVE-2026-68160 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path. Cc: stable(a)vger.kernel.org Fixes: a8599bd821d0 ("ceph: capability management") Signed-off-by: Bryam Vargas <hexlabsecurity(a)proton.me> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Conflicts: fs/ceph/caps.c [Context conflicts unmerged commit 8ea412e18131 ("ceph: improve caps debugging output")] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- fs/ceph/caps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index 8c1dd9e80e7e..31e5d87ec945 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -4124,10 +4124,11 @@ void ceph_handle_caps(struct ceph_mds_session *session, seq = le32_to_cpu(h->seq); mseq = le32_to_cpu(h->migrate_seq); snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); + ceph_decode_need(&snaptrace, end, snaptrace_len, bad); p = snaptrace + snaptrace_len; if (msg_version >= 2) { u32 flock_len; ceph_decode_32_safe(&p, end, flock_len, bad); -- 2.34.1

2 1

[PATCH OLK-6.6] cdrom: fix stack out-of-bounds read in CDROMVOLCTRL
by Fanhua Li 18 Aug '26

18 Aug '26

From: Xu Rao <raoxu(a)uniontech.com> stable inclusion from stable-v6.6.148 commit 7344c84e32413e5c8832f74b8a612b0194e5c051 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17022 CVE: CVE-2026-68184 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b27e195d4db8dea263050bdbeb11881b2999c9c6 upstream. mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Xu Rao <raoxu(a)uniontech.com> Signed-off-by: Phillip Potter <phil(a)philpotter.co.uk> Link: https://patch.msgid.link/20260720194421.1497-2-phil@philpotter.co.uk Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/cdrom/cdrom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 2283fd91ff5f8..c638f6a9bc7d6 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -3191,6 +3191,7 @@ static noinline int mmc_ioctl_cdrom_volume(struct cdrom_device_info *cdi, /* set volume */ cgc->buffer = buffer + offset - 8; + cgc->buflen -= offset - 8; memset(cgc->buffer, 0, 8); return cdrom_mode_select(cdi, cgc); } -- 2.43.0

2 1

[PATCH OLK-6.6] openeuler_defconfig: Enable Landlock (testing)
by GONG Ruiqi 18 Aug '26

18 Aug '26

hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9681 -------------------------------- Test only. Do NOT merge. Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 4 ++-- arch/x86/configs/openeuler_defconfig | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 9c6d128276cd..1816509a5041 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -7482,7 +7482,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -7539,7 +7539,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 685c32d1e7af..ec621167398d 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -8667,7 +8667,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -8724,7 +8724,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options -- 2.43.0

2 1

[PATCH OLK-6.6 0/8] irqbypass: Cleanups and a perf improvement
by Qiqi Li 17 Aug '26

17 Aug '26

From: Qiqi Li <liqiqi23(a)huawei.com> The two primary goals of this series are to make the irqbypass concept easier to understand, and to address the terrible performance that can result from using a list to track connections. Provides additional adaptation for the ub vfio device in openEuler. Sean Christopherson (8): irqbypass: Drop pointless and misleading THIS_MODULE get/put irqbypass: Drop superfluous might_sleep() annotations irqbypass: Take ownership of producer/consumer token tracking irqbypass: Explicitly track producer and consumer bindings irqbypass: Use paired consumer/producer to disconnect during unregister irqbypass: Use guard(mutex) in lieu of manual lock+unlock irqbypass: Use xarray to track producers and consumers irqbypass: Require producers to pass in Linux IRQ number during registration arch/x86/kvm/x86.c | 4 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- drivers/vfio/ubus/vfio_ub_intrs.c | 11 +- drivers/vhost/vdpa.c | 10 +- include/linux/irqbypass.h | 46 ++++---- virt/kvm/eventfd.c | 7 +- virt/lib/irqbypass.c | 190 +++++++++++------------------- 7 files changed, 111 insertions(+), 167 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6 0/8] irqbypass: Cleanups and a perf improvement
by Qiqi Li 17 Aug '26

17 Aug '26

From: Qiqi Li <liqiqi23(a)huawei.com> The two primary goals of this series are to make the irqbypass concept easier to understand, and to address the terrible performance that can result from using a list to track connections. Provides additional adaptation for the ub vfio device in openEuler. Sean Christopherson (8): irqbypass: Drop pointless and misleading THIS_MODULE get/put irqbypass: Drop superfluous might_sleep() annotations irqbypass: Take ownership of producer/consumer token tracking irqbypass: Explicitly track producer and consumer bindings irqbypass: Use paired consumer/producer to disconnect during unregister irqbypass: Use guard(mutex) in lieu of manual lock+unlock irqbypass: Use xarray to track producers and consumers irqbypass: Require producers to pass in Linux IRQ number during registration arch/x86/kvm/x86.c | 4 +- drivers/vfio/pci/vfio_pci_intrs.c | 10 +- drivers/vfio/ubus/vfio_ub_intrs.c | 11 +- drivers/vhost/vdpa.c | 10 +- include/linux/irqbypass.h | 46 ++++---- virt/kvm/eventfd.c | 7 +- virt/lib/irqbypass.c | 190 +++++++++++------------------- 7 files changed, 111 insertions(+), 167 deletions(-) -- 2.43.0

2 9

[PATCH OLK-6.6] openeuler_defconfig: Enable Landlock (kABI testing)
by GONG Ruiqi 17 Aug '26

17 Aug '26

hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9681 -------------------------------- KABI test only. Do NOT merge. Signed-off-by: GONG Ruiqi <gongruiqi1(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 4 ++-- arch/x86/configs/openeuler_defconfig | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index 9c6d128276cd..1816509a5041 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -7482,7 +7482,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -7539,7 +7539,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 685c32d1e7af..ec621167398d 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -8667,7 +8667,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y @@ -8724,7 +8724,7 @@ CONFIG_EVM_X509_PATH="/etc/keys/x509_evm.der" CONFIG_DEFAULT_SECURITY_SELINUX=y # CONFIG_DEFAULT_SECURITY_APPARMOR is not set # CONFIG_DEFAULT_SECURITY_DAC is not set -CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" +CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" # # Kernel hardening options -- 2.43.0

2 1

[PATCH OLK-6.6] tracing/user_events: Fix use-after-free in user_event_mm_dup()
by Tengda Wu 17 Aug '26

17 Aug '26

From: Michael Bommarito <michael.bommarito(a)gmail.com> stable inclusion from stable-v6.6.148 commit 25acb6711da6fa0382744fa92bd6d42a22c1ae68 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17268 CVE: CVE-2026-72071 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 50fd6dd755c6e48a38af2fa4621167eea56829c2 ] user_event_mm_dup() walks the parent mm's enabler list locklessly under rcu_read_lock() during fork() (from copy_process()); it does not take event_mutex: rcu_read_lock(); list_for_each_entry_rcu(enabler, &old_mm->enablers, mm_enablers_link) enabler->event = user_event_get(orig->event); user_event_enabler_destroy() removes an enabler from that list with list_del_rcu() and then, without waiting for a grace period, drops the enabler's user_event reference with user_event_put() and frees the enabler with kfree(). A reader that loaded the enabler before the list_del_rcu() can still be walking it, which leads to two use-after-frees: - kfree(enabler) frees the enabler while that reader dereferences enabler->event. - user_event_put() may drop the last reference to the user_event, which is then freed (via delayed_destroy_user_event() on a work queue), while the same reader does user_event_get(orig->event) on it. Both are reachable by an unprivileged task that can open user_events_data: one multithreaded process that registers an enabler and then concurrently unregisters it and calls fork() triggers the race. KASAN reports a slab-use-after-free in user_event_mm_dup() during clone(), with a "refcount_t: addition on 0" warning when the user_event is freed. The enabler use-after-free was found first; the user_event one was reported by XIAO WU, and the earlier enabler-only fix did not address it. Defer both the user_event_put() and the kfree(enabler) to a work item queued with queue_rcu_work(), so they run only after an RCU grace period, once all readers walking the enabler list have finished. The put must run in process context because user_event_put() takes event_mutex on the last reference, so a work queue is used rather than call_rcu(). The now-unlocked put lets the locked argument of user_event_enabler_destroy() be removed; all callers are updated. Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event enablement") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260707165912.2560537-2-michael.bommarito@gmail.c… Reported-by: XIAO WU <xiaowu.417(a)qq.com> Closes: https://lore.kernel.org/all/tencent_89647CE40DC452B891C65C94D1B271DE8E07@qq… Suggested-by: Beau Belgrave <beaub(a)linux.microsoft.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace_events_user.c | 39 ++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 7 deletions(-) diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c index 2461786b1e4d..9dabeb86acd1 100644 --- a/kernel/trace/trace_events_user.c +++ b/kernel/trace/trace_events_user.c @@ -104,6 +104,9 @@ struct user_event_enabler { /* Track enable bit, flags, etc. Aligned for bitops. */ unsigned long values; + + /* Defer the event put and enabler free past an RCU grace period. */ + struct rcu_work put_rwork; }; /* Bits 0-5 are for the bit to update upon enable/disable (0-63 allowed) */ @@ -378,17 +381,39 @@ static struct user_event_group *user_event_group_create(void) return NULL; }; -static void user_event_enabler_destroy(struct user_event_enabler *enabler, - bool locked) +static void delayed_user_event_enabler_put(struct work_struct *work) { - list_del_rcu(&enabler->mm_enablers_link); + struct user_event_enabler *enabler = container_of(to_rcu_work(work), + struct user_event_enabler, put_rwork); /* No longer tracking the event via the enabler */ - user_event_put(enabler->event, locked); + user_event_put(enabler->event, false); + /* Run from queue_rcu_work(), the RCU grace period has elapsed */ kfree(enabler); } +static void user_event_enabler_destroy(struct user_event_enabler *enabler) +{ + list_del_rcu(&enabler->mm_enablers_link); + + /* + * The enabler is removed from an RCU-traversed list + * (user_event_mm_dup() walks mm->enablers under rcu_read_lock() only), + * and readers there dereference enabler->event and take a new ref on + * it. Both the put of that event reference and the free of the enabler + * therefore have to wait for a grace period so no reader can be looking + * at the enabler or racing the last put of its event. + * + * The put itself must not run in RCU context: when it drops the last + * reference user_event_put() takes event_mutex, which cannot be taken + * from a softirq/RCU callback. Defer both to a work item scheduled + * after a grace period via queue_rcu_work(). + */ + INIT_RCU_WORK(&enabler->put_rwork, delayed_user_event_enabler_put); + queue_rcu_work(system_percpu_wq, &enabler->put_rwork); +} + static int user_event_mm_fault_in(struct user_event_mm *mm, unsigned long uaddr, int attempt) { @@ -446,7 +471,7 @@ static void user_event_enabler_fault_fixup(struct work_struct *work) /* User asked for enabler to be removed during fault */ if (test_bit(ENABLE_VAL_FREEING_BIT, ENABLE_BITOPS(enabler))) { - user_event_enabler_destroy(enabler, true); + user_event_enabler_destroy(enabler); goto out; } @@ -746,7 +771,7 @@ static void user_event_mm_destroy(struct user_event_mm *mm) struct user_event_enabler *enabler, *next; list_for_each_entry_safe(enabler, next, &mm->enablers, mm_enablers_link) - user_event_enabler_destroy(enabler, false); + user_event_enabler_destroy(enabler); mmdrop(mm->mm); kfree(mm); @@ -2579,7 +2604,7 @@ static long user_events_ioctl_unreg(unsigned long uarg) flags |= enabler->values & ENABLE_VAL_COMPAT_MASK; if (!test_bit(ENABLE_VAL_FAULTING_BIT, ENABLE_BITOPS(enabler))) - user_event_enabler_destroy(enabler, true); + user_event_enabler_destroy(enabler); /* Removed at least one */ ret = 0; -- 2.34.1

2 1

[PATCH OLK-6.6] tracing: Check return value of __register_event() in trace_module_add_events()
by Tengda Wu 17 Aug '26

17 Aug '26

From: "Masami Hiramatsu (Google)" <mhiramat(a)kernel.org> stable inclusion from stable-v6.6.151 commit d61ee2a27dfd5eb43ddc18af40168f5b9eb1cea5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/17265 CVE: CVE-2026-74471 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ac8719969e6c3c54e939834df812bc41f25453cf upstream. trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded. Fixes: ae63b31e4d0e ("tracing: Separate out trace events from global variables") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/178528487878.124250.14170824576025743236.stgit@dev… Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/trace_events.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 55b5346cb3d5..bea0ab4d8d73 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -3314,8 +3314,8 @@ static void trace_module_add_events(struct module *mod) end = mod->trace_events + mod->num_trace_events; for_each_event(call, start, end) { - __register_event(*call, mod); - __add_event_to_tracers(*call); + if (!__register_event(*call, mod)) + __add_event_to_tracers(*call); } } -- 2.34.1

2 1