**[UPDATE — CVE-2026-23416 now officially published 2026-04-02]**

---

**Status:** CVE reserved 2026-01-13, officially published 2026-04-02 by Linux kernel CNA.

The CVE is now live:
- https://www.cve.org/CVERecord?id=CVE-2026-23416
- https://nvd.nist.gov/vuln/detail/CVE-2026-23416

PoC + README published:
- https://github.com/bluedragonsecurity/CVE-2026-23416-POC

Medium writeup:
- https://medium.com/@w1sdom/cve-2026-23416-poc-affecting-linux-kernel-6-17-linux-kernel-7-0-rc-5-457afc9ad9e3

---

**Upstream fix description (from commit message):**

The official fix title is `mm/mseal: update VMA end correctly on merge`. The upstream commit clarifies the root cause at the loop level: `mseal_apply()` stores `curr_end = vma->vm_end`, then on the next iteration sets `curr_start = curr_end` to advance. But `vma_modify_flags()` can merge VMAs mid-loop, making `curr_end` stale — so `curr_start` on the next iteration ends up incorrect. This is the same inconsistency that surfaces as the `vmg->start != middle->vm_start` assertion failure described in the original post, just described from the loop variable perspective rather than the vmg state perspective.

Fix: set `curr_end = vma->vm_end` unconditionally on each iteration, and clamp `curr_[start/end]` as `const` values. Applied in 7.0-rc6.

Fix commits (three stable backports):
- `40b3f4700e5535fbe74738cebb9379a40ec66bed`
- `83737e34b83a23b2a9bcf586b058b2c2a54c7c6b`
- `2697dd8ae721db4f6a53d4f4cbd438212a80f8dc`

Fixed in: **7.0-rc6**, **6.18.21**, **6.19.11**

---

**Confirmed dmesg output on Linux 7.0.0-rc5 (actual kernel, not QEMU mock):**

```
[237.650564]  vma_modify_flags+0x24c/0x3c0
[237.650599]  ? __pfx_vma_modify_flags+0x10/0x10
[237.650662]  do_mseal+0x489/0x860
[237.650738]  ? __pfx_do_mseal+0x10/0x10
[237.650874]  __x64_sys_mseal+0x73/0xb0
[237.650907]  do_syscall_64+0x111/0x690
[237.650933]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
[237.651014]  RDX: 0000000000000000  RSI: 0000000000070000  RDI: 0000000021da6000
...
Linux robohax-standardpc 7.0.0-rc5 #1 SMP PREEMPT_DYNAMIC Wed Mar 25 05:31:07 EDT 2026 x86_64
```

`RDI=0x21da6000` is the mseal start (m2), `RSI=0x70000` is the length — exactly matching PoC step 2. Stack trace confirms the full call path: `mseal(2)` → `do_mseal()` → `vma_modify_flags()`.