CVE-2026-23416
published 2026-04-02CVE-2026-23416: 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…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.22%
12.3th percentile
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
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.19.11-1 (sid) | linux 6.19.11-1 (sid) |
| linux | linux | — | — |
| linux | linux | >= 6c2da14ae1e0a0146587381594559027bd46c059 < 40b3f4700e5535fbe74738cebb9379a40ec66bed | 40b3f4700e5535fbe74738cebb9379a40ec66bed |
| linux | linux | >= 6c2da14ae1e0a0146587381594559027bd46c059 < 83737e34b83a23b2a9bcf586b058b2c2a54c7c6b | 83737e34b83a23b2a9bcf586b058b2c2a54c7c6b |
| linux | linux | >= 6c2da14ae1e0a0146587381594559027bd46c059 < 2697dd8ae721db4f6a53d4f4cbd438212a80f8dc | 2697dd8ae721db4f6a53d4f4cbd438212a80f8dc |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 6.17.1 < 6.18.21 | 6.18.21 |
| linux | linux_kernel | >= 6.19 < 6.19.11 | 6.19.11 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 6.18.20/6.19.10/7.0-rc5 vma_modify_flags iteration (EUVD-2026-18198 / WID-SEC-2026-0985)
vuldb·2026-06-24·CVSS 5.5
CVE-2026-23416 [MEDIUM] Linux Kernel up to 6.18.20/6.19.10/7.0-rc5 vma_modify_flags iteration (EUVD-2026-18198 / WID-SEC-2026-0985)
A vulnerability has been found in Linux Kernel up to 6.18.20/6.19.10/7.0-rc5 and classified as critical. Affected by this issue is the function vma_modify_flags. Performing a manipulation results in excessive iteration.
This vulnerability is identified as CVE-2026-23416. The attack can only be performed from the local network. There is not any exploit available.
The affected component should be upgraded.
OSV
CVE-2026-23416: (In the Linux kernel, the following vulnerability has been resolved: m
osv·2026-04-03
CVE-2026-23416 CVE-2026-23416: (In the Linux kernel, the following vulnerability has been resolved: m
(In the Linux kernel, the following vulnerability has been resolved: m ...)
OSV
CVE-2026-23416: 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 cu
osv·2026-04-02
CVE-2026-23416 CVE-2026-23416: 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 cu
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, w
GHSA
GHSA-h9cv-r6cj-w8vj: 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
ghsa_unreviewed·2026-04-02
CVE-2026-23416 GHSA-h9cv-r6cj-w8vj: 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
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 VM
Red Hat
kernel: mm/mseal: update VMA end correctly on merge
vendor_redhat·2026-04-02
CVE-2026-23416 CWE-825 kernel: mm/mseal: update VMA end correctly on merge
kernel: mm/mseal: update VMA end correctly on merge
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_[st
Debian
CVE-2026-23416: linux - In the Linux kernel, the following vulnerability has been resolved: mm/mseal: u...
vendor_debian·2026
CVE-2026-23416 [LOW] CVE-2026-23416: linux - In the Linux kernel, the following vulnerability has been resolved: mm/mseal: u...
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, w
No detection rules found.
No public exploits indexed.
2026-04-02
Published