CVE-2025-40040: mm/ksm: fix flag-dropping behavior in ksm_madvise
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------
[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!
[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)
[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace:
[ 44.617926] <TASK>
[ 44.619284] userfaultfd_release+0xef/0x1b0
[ 44.620976] __fput+0x3f9/0xb60
[ 44.621240] fput_close_sync+0x110/0x210
[ 44.622222] __x64_sys_close+0x8f/0x120
[ 44.622530] do_syscall_64+0x5b/0x2f0
[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during
userfaultfd_release_all(). Specifically, a VMA which has a valid pointer
to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise()
with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,
it accidentally clears all flags stored in the upper 32 bits of
vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and
int are 32-bit wide. This setup causes the following mishap during the &=
~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000.
After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then
promoted to unsigned long before the & operation. This promotion fills
upper 32 bits with leading 0s, as we're doing unsigned conversion (and
even for a signed conversion, this wouldn't help as the leading bit is 0).
& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff
instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears
the upper 32-bits of its value.
Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the
BIT() macro.
Note: other VM_* flags are not affected: This only happens to the
VM_MERGEABLE flag, as the other VM_* flags are all constants of type int
and after ~ operation, they end up with leading 1 and are thus converted
to unsigned long with leading 1s.
Note 2:
After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is
no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]
Security readout for executives and security teams
Plain-English summary
A Linux kernel memory-management bug can corrupt internal flags when a local process combines KSM advice with userfaultfd MINOR registration. The demonstrated result is a kernel crash on some kernels, or a warning after a later change. Exposure is narrower than a network-facing flaw, but affected systems allowing untrusted local workloads merit prompt kernel updates.
Executive priority
Treat this as a high-priority local kernel issue, especially on shared systems or hosts running untrusted workloads. It is not evidenced as an internet-exploitable or actively exploited vulnerability. Schedule vendor kernel updates promptly, while validating exact package exposure to avoid unnecessary emergency changes caused by ambiguous upstream version data.
Technical view
During MADV_UNMERGEABLE processing, the 32-bit VM_MERGEABLE complement is promoted with zero-filled upper bits on the described x86_64 build. The resulting mask clears every upper 32-bit VMA flag, including userfaultfd flags. userfaultfd_release_all then detects a VMA context without matching flags. Stable fixes define VM_MERGEABLE as unsigned long using BIT().
Likely exposure
Exposure requires an affected Linux kernel, local low-privilege execution, KSM-related memory advice, and userfaultfd MINOR registration. The bundle names Linux 4.6 and numerous 5.x and 6.x releases, but its version representation does not establish reliable continuous ranges. Confirm exposure using distribution advisories or applicable stable-branch fixes.
Exploitation context
The CVE is not listed as KEV, and no supplied source reports active exploitation. The evidence is a syzkaller-discovered crash with a reproducer. CVSS 3.1 rates it 7.8 with local access, low complexity, low privileges, no user interaction, and potentially high confidentiality, integrity, and availability impact.
Researcher notes
The failure is a type-width masking error specific to VM_MERGEABLE; the bundle states other VM_* constants are unaffected. A later userfaultfd change converts the observed kernel BUG into a WARNING but does not remove the underlying flag loss. The supplied material demonstrates inconsistency and crash behavior, but provides no public evidence of weaponization or real-world compromise.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable stable-branch fix for CVE-2025-40040.
Consult the Linux distribution or kernel vendor for exact affected and corrected package versions.
If updating is delayed, request vendor-approved mitigations; the supplied sources identify no workaround.
Prioritize systems where untrusted users or workloads can invoke affected kernel memory-management features.
Validation and detection
Inventory running kernel versions, architectures, distribution package revisions, and build provenance.
Map each kernel to its vendor advisory or the applicable referenced stable-branch fix.
After updating, reboot and confirm the corrected kernel is actually running.
Review kernel logs for userfaultfd_release_all BUG or WARNING events; absence alone does not prove safety.
Confirm vulnerability scanners use corrected vendor version mappings rather than broad upstream version assumptions.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-40040 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
9Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.