Answer in brief
CVE-2026-53341 records a Unknown severity vulnerability in fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=620c266f394932e5decc4b34683a75dfc59dc2f4 <15ea8dc42a02259d49dee38a658d40f60fcd75ed || >=620c266f394932e5decc4b34683a75dfc59dc2f4 <32138633e51e6db59e474765cf93268c92b42888 || >=620c266f394932e5decc4b34683a75dfc59dc2f4 <a8ed2c29fcfdac78db96c9da4e659c8a513f2a94 || >=620c266f394932e5decc4b34683a75dfc59dc2f4 <40ab6644b99685755f740b872c00ef40d9aa870e | 15ea8dc42a02259d49dee38a658d40f60fcd75ed, 32138633e51e6db59e474765cf93268c92b42888, a8ed2c29fcfdac78db96c9da4e659c8a513f2a94, 40ab6644b99685755f740b872c00ef40d9aa870e |
| Linux/Linuxgeneric | 6.11 | Not reported |
Published upstream
Jul 1, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 1, 2026
In the Linux kernel, the following vulnerability has been resolved: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-53341 records a Unknown severity vulnerability in fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=620c266f394932e5decc4b34683a75dfc59dc2f4 <15ea8dc42a02259d49dee38a658d40f60fcd75ed || >=620c266f394932e5decc4b34683a75dfc59dc2f4 <32138633e51e6db59e474765cf93268c92b42888 || >=620c266f394932e5decc4b34683a75dfc59dc2f4 <a8ed2c29fcfdac78db96c9da4e659c8a513f2a94 || >=620c266f394932e5decc4b34683a75dfc59dc2f4 <40ab6644b99685755f740b872c00ef40d9aa870e | 15ea8dc42a02259d49dee38a658d40f60fcd75ed, 32138633e51e6db59e474765cf93268c92b42888, a8ed2c29fcfdac78db96c9da4e659c8a513f2a94, 40ab6644b99685755f740b872c00ef40d9aa870e |
| Linux/Linuxgeneric | 6.11 | Not reported |
Published upstream
Jul 1, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 1, 2026
In the Linux kernel, the following vulnerability has been resolved: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address.
Quoted source text, attributed separately from HOL analysis.