mm/mseal: update VMA end correctly on merge
23Vexday Risk Score
No sign of exploitation. It has a public proof of concept.
ssvc Attendepss 0.2%
from disclosure to weapon0 days
Published on NVDApr 2
1st PoCApr 2
exploitation probability
0.2%top 88% of all CVEs
observed exploitation
nono source reports it
1 public exploit(s)
In the Linux kernel, the following vulnerability has been resolved:
mm/mseal: update VMA end correctly on merge
Previously we stored the end of the current VMA in curr_end, and then upon
iterating to the next VMA updated curr_start to curr_end to advance to the
next VMA.
However, this doesn't take into account the fact that a VMA might be
updated due to a merge by vma_modify_flags(), which can result in curr_end
being stale and thus, upon setting curr_start to curr_end, ending up with
an incorrect curr_start on the next iteration.
Resolve the issue by setting curr_end to vma->vm_end unconditionally to
ensure this value remains updated should this occur.
While we're here, eliminate this entire class of bug by simply setting
const curr_[start/end] to be clamped to the input range and VMAs, which
also happens to simplify the logic.
Affected products
Linux · Linuxpublic PoCs found — 1
githubgithub.com/bluedragonsecurity/CVE-2026-23416-POC★ 8⚠ Public resources, to assess the exposure of systems you control or are authorized to test. Test only with authorization.