[BUG] mm/vma.c:830 WARNING in vma_modify() via mseal(2) -- deterministic trigger without fault injection on Linux 7.0-rc5

From: antonius

Date: Fri Mar 27 2026 - 03:48:22 EST

Hello,

I am reporting a reproducible WARNING in vma_modify() at mm/vma.c:830,
triggered via the mseal(2) syscall on Linux 7.0.0-rc5. The bug was
discovered using Syzkaller-based fuzzing.

REPORTER
--------
Antonius / Blue Dragon Security
https://bluedragonsec.com
https://github.com/bluedragonsecurity

NOTE ON RELATIONSHIP TO KNOWN BUGS
-----------------------------------
The VM_WARN_ON_VMG at mm/vma.c:830 inside vma_merge_existing_range()
has been previously encountered via madvise()+OOM conditions
(reported by syzbot+46423ed8fa1f1148c6e4 and Brad Spengler; addressed
by Lorenzo's patch "mm: abort vma_modify() on merge out of memory
failure").

This report describes a DISTINCT trigger via mseal(2) that:
  1. Does NOT require fault injection or OOM pressure
  2. Is 100% reproducible on every run (fires within 1 second)
  3. Goes through a different call path: do_mseal() -> mseal_apply()
     rather than madvise_walk_vmas()
  4. Is triggered by VM_SEALED flag state inconsistency across VMAs,
     not by a failed merge commit

I could not find a prior LKML report or syzbot entry for this specific
mseal(2) trigger.

SUMMARY
-------
File:    mm/vma.c, line 830
Func:    vma_merge_existing_range()
Trigger: mseal() spanning two adjacent VMAs where the first has
         VM_SEALED set and the second does not
Via:     mseal(2) -> do_mseal() -> mseal_apply() ->
         vma_modify_flags() -> vma_modify() ->
         vma_merge_existing_range() -> VM_WARN_ON_VMG

AFFECTED VERSIONS
-----------------
Linux 7.0-rc3  -- confirmed (original fuzzing target)
Linux 7.0-rc4  -- confirmed (mm/vma.c unchanged rc3->rc4)
Linux 7.0-rc5  -- confirmed (mm/vma.c unchanged rc4->rc5)
Linux 6.x      -- NOT affected (mm/vma.c rewritten for 7.0)

DMESG OUTPUT (Linux 7.0.0-rc5, trimmed)
----------------------------------------

  [ 1680.275764] ------------[ cut here ]------------
  [ 1680.275771] WARNING: mm/vma.c:830 at vma_modify+0x35b/0x2190
  [ 1680.275808] CPU: 0 UID: 1000 PID: 1661 Comm: repro_mseal_vma
  [ 1680.275826] Tainted: [W]=WARN  7.0.0-rc5 #1 PREEMPT(lazy)
  [ 1680.275969] Call Trace:
  [ 1680.275975]  <TASK>
  [ 1680.276030]  vma_modify_flags+0x24c/0x3c0
  [ 1680.276085]  do_mseal+0x489/0x860
  [ 1680.276136]  __x64_sys_mseal+0x73/0xb0
  [ 1680.276187]  do_syscall_64+0x111/0x690
  [ 1680.276207]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
  [ 1680.276394] ---[ end trace 0000000000000000 ]---

  [ 1680.314910] vmg dumped because:
    VM_WARN_ON_VMG(middle &&
      ((middle != prev && vmg->start != middle->vm_start) ||
       vmg->end > middle->vm_end))

  vmg state:
    vmi [21de6000, 21e83000)
    prev   [21da6000-21de6000)  flags: 0x400000000f8 (VM_SEALED set)
    middle [21de6000-21e83000)  flags: 0xf8           (NOT sealed)
    vmg->start = 0x21da8000
    vmg->end   = 0x21e16000

ROOT CAUSE
----------
The bug is in vma_merge_existing_range() at mm/vma.c:830.

Reproduction sequence:

  1. memfd_create("syz-mseal", MFD_CLOEXEC)  -> fd1
  2. mmap(0x21da8000, 0xdd000, PROT_SEM, MAP_SHARED|MAP_FIXED, fd1, 0)
     -> establishes VMA at [0x21da8000 .. 0x21e85000)

  3. memfd_create("syz-mseal", MFD_CLOEXEC)  -> fd2
  4. mmap(0x21da6000, 0xdd000, PROT_SEM, MAP_SHARED|MAP_FIXED, fd2, 0)
     -> remaps, leaving:
          VMA-A [0x21da6000 - 0x21de6000)  pgoff=0    (fd2)
          VMA-B [0x21de6000 - 0x21e83000)  pgoff=0x40 (fd2)
          VMA-C [0x21e83000 - 0x21e85000)  (leftover)

  5. mseal(mmap1_result, 0x3e000, 0)
     -> seals [0x21da8000 .. 0x21de5fff]
     -> VMA-A gets VM_SEALED (0x400000000000) set

  6. mseal(mmap2_result, 0x70000, 0)
     -> targets [0x21da6000 .. 0x21e15fff]
     -> range spans VMA-A (sealed) and VMA-B (not sealed)

In step 6, do_mseal() calls mseal_apply() per-VMA but ultimately
calls vma_modify_flags() with the original full mseal start address
(0x21da8000). When vma_merge_existing_range() processes VMA-B as
"middle":

  vmg->start        = 0x21da8000  (original mseal start)
  middle->vm_start  = 0x21de6000  (VMA-B start)
  middle != prev                  (different VMA objects)

  -> vmg->start != middle->vm_start  -> WARN_ON fires at line 830

The invariant violation occurs because the vmg->start passed to
vma_modify_flags() is not clamped to the current VMA's start when
the mseal range spans multiple VMAs with different VM_SEALED states.

IMPACT
------
- Reachable from unprivileged userspace (UID 1000, no capabilities)
- Only memfd_create(2), mmap(2), mseal(2) required
- The WARN_ON indicates that vma_merge_existing_range() operates on
  an inconsistent vmg state; in production kernels with WARN compiled
  to no-op, this could result in VMA tree state inconsistency
- mseal is a security primitive; invariant violations in its
  application logic are security-relevant

SUGGESTED FIX DIRECTION
------------------------
In do_mseal() or mseal_apply() (mm/mseal.c), when iterating over
VMAs in the mseal range, the vmg->start passed to vma_modify_flags()
should be clamped to max(mseal_start, vma->vm_start) rather than
using the original mseal() start address. This would prevent
vma_merge_existing_range() from receiving a vmg->start that is
inconsistent with vmg->middle when the mseal range spans multiple
VMAs with different seal states.

Alternatively, the WARN_ON in vma_merge_existing_range() may need
to account for the mseal multi-VMA iteration pattern, though fixing
the caller in do_mseal() seems more appropriate.

REPRODUCER
----------
Compile: gcc -O2 -o repro repro_mseal_vma.c && ./repro
Fires:   Within 1 second, iteration 0, no fault injection, no root

  #define _GNU_SOURCE
  #include <stdint.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include <sys/syscall.h>
  #include <sys/wait.h>
  #include <unistd.h>

  #ifndef __NR_memfd_create
  #define __NR_memfd_create 319
  #endif
  #ifndef __NR_mseal
  #define __NR_mseal 462
  #endif

  static void setup(void) {
    syscall(__NR_mmap, 0x1ffffffff000UL, 0x1000UL, 0UL, 0x32UL, -1, 0UL);
    syscall(__NR_mmap, 0x200000000000UL, 0x1000000UL, 7UL, 0x32UL, -1, 0UL);
    syscall(__NR_mmap, 0x200001000000UL, 0x1000UL, 0UL, 0x32UL, -1, 0UL);
  }

  static void trigger(void) {
    intptr_t fd1, fd2, m1, m2;
    memcpy((void*)0x200000000100UL, "syz-mseal\0", 10);
    fd1 = syscall(__NR_memfd_create, 0x200000000100UL, 1UL);
    if (fd1 < 0) return;
    m1 = syscall(__NR_mmap, 0x21da8000UL, 0xdd000UL,
                 8UL, 0x11UL, (intptr_t)fd1, 0UL);
    memcpy((void*)0x200000000100UL, "syz-mseal\0", 10);
    fd2 = syscall(__NR_memfd_create, 0x200000000100UL, 1UL);
    if (fd2 < 0) return;
    m2 = syscall(__NR_mmap, 0x21da6000UL, 0xdd000UL,
                 8UL, 0x11UL, (intptr_t)fd2, 0UL);
    syscall(__NR_mseal, (uint64_t)m1, 0x3e000UL, 0UL);
    syscall(__NR_mseal, (uint64_t)m2, 0x70000UL, 0UL);
  }

  int main(void) {
    setup();
    for (int i = 0;; i++) {
      int pid = fork();
      if (pid == 0) { trigger(); _exit(0); }
      int st; waitpid(pid, &st, 0);
      fprintf(stderr, "[iter %d]\n", i);
    }
  }

VERIFICATION
------------
Kernel:    Linux 7.0.0-rc5 #1 SMP PREEMPT_DYNAMIC x86_64
HW:        QEMU Standard PC (i440FX + PIIX), BIOS 1.17.0-debian
User:      UID 1000 (no root required)
Fires:     Iteration 0, consistently, < 1 second
mm/vma.c:  Not patched in rc3->rc4 or rc4->rc5

---
Reported-by: Antonius <antonius@xxxxxxxxxxxxxxxxx>

Please use this tag in the fix commit:
  Reported-by: Antonius <antonius@xxxxxxxxxxxxxxxxx>

---
If this is a known issue or already fixed, please point me to the
relevant commit. I was unable to find a matching LKML/syzbot entry
for this specific mseal(2) trigger path.

Thank you,
Antonius
Blue Dragon Security
https://bluedragonsec.com
https://github.com/bluedragonsecurity

// SPDX-License-Identifier: GPL-2.0
/*
* Reproducer: WARNING in vma_modify() at mm/vma.c:830
*
* Trigger: mseal(2) spanning two adjacent VMAs where the first
* has been partially sealed (VM_SEALED set), the second
* has not. vma_merge_existing_range() fires WARN_ON because
* vmg->start != middle->vm_start with middle != prev.
*
* Affected: Linux 7.0-rc3, 7.0-rc4, 7.0-rc5 (confirmed)
* mm/vma.c untouched in rc3->rc4 and rc4->rc5 patches.
* Not present in Linux 6.x (mm/vma.c rewritten for 7.0).
*
* Note: The same WARN at mm/vma.c:830 is known to trigger via
* madvise()+OOM (syzbot+46423ed8fa1f1148c6e4). This
* reproducer demonstrates a DISTINCT trigger via mseal(2)
* that requires NO fault injection and fires deterministically.
*
* Reporter: Antonius / Blue Dragon Security
* https://bluedragonsec.com
* https://github.com/bluedragonsecurity
*
* Compile: gcc -O2 -o repro_mseal_vma repro_mseal_vma.c
* Run: ./repro_mseal_vma
* Verify: dmesg | grep 'WARNING.*vma\.c:830'
* (fires within iteration 0, < 1 second, no root needed)
*
* Call path:
* mseal(2)
* -> do_mseal() [mm/mseal.c]
* -> mseal_apply()
* -> vma_modify_flags() [mm/vma.c]
* -> vma_modify()
* -> vma_merge_existing_range()
* -> VM_WARN_ON_VMG at line 830 <-- fires here
*
* Condition that triggers WARN:
* VM_WARN_ON_VMG(middle &&
* ((middle != prev && vmg->start != middle->vm_start) ||
* vmg->end > middle->vm_end))
*
* vmg->start = 0x21da8000 (from first mseal context)
* middle->vm_start = 0x21de6000 (VMA-B, not sealed)
* -> vmg->start != middle->vm_start -> WARN fires
*/

#define _GNU_SOURCE
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/wait.h>
#include <unistd.h>

#ifndef __NR_memfd_create
#define __NR_memfd_create 319
#endif
#ifndef __NR_mseal
#define __NR_mseal 462
#endif

/* ---------------------------------------------------------------
* Fixed workspace layout (syzbot-style)
* These three mmaps establish a predictable address space so that
* the trigger addresses 0x21daXXXX fall within mapped memory.
* --------------------------------------------------------------- */
static void setup_workspace(void)
{
syscall(__NR_mmap,
(uint64_t)0x1ffffffff000UL, (uint64_t)0x1000UL,
(uint64_t)0UL, (uint64_t)0x32UL, /* MAP_FIXED|MAP_ANON|MAP_PRIVATE */
(intptr_t)-1, (uint64_t)0UL);

syscall(__NR_mmap,
(uint64_t)0x200000000000UL, (uint64_t)0x1000000UL,
(uint64_t)7UL, /* PROT_READ|WRITE|EXEC */
(uint64_t)0x32UL,
(intptr_t)-1, (uint64_t)0UL);

syscall(__NR_mmap,
(uint64_t)0x200001000000UL, (uint64_t)0x1000UL,
(uint64_t)0UL, (uint64_t)0x32UL,
(intptr_t)-1, (uint64_t)0UL);
}

/* ---------------------------------------------------------------
* Core trigger.
*
* After the two mmaps + first mseal, memory layout is:
*
* [0x21da6000 - 0x21de5fff] VMA-A (fd2, MAP_SHARED|MAP_FIXED)
* ^-- first mseal() sets VM_SEALED here
* [0x21de6000 - 0x21e82fff] VMA-B (fd2, MAP_SHARED|MAP_FIXED)
* ^-- NOT sealed when second mseal fires
* [0x21e83000 - 0x21e84fff] VMA-C (leftover)
*
* Second mseal(mmap2_result, 0x70000) targets [0x21da6000-0x21e15fff],
* spanning VMA-A (sealed) into VMA-B (not sealed).
*
* Inside do_mseal() -> mseal_apply() -> vma_modify_flags():
* The call passes the original full mseal start (0x21da8000 from the
* first mseal context) as vmg->start. When vma_merge_existing_range()
* is invoked for VMA-B (middle=[0x21de6000..]):
*
* vmg->start (0x21da8000) != middle->vm_start (0x21de6000)
* AND middle != prev
* -> VM_WARN_ON_VMG fires at mm/vma.c:830
* --------------------------------------------------------------- */
static void trigger(void)
{
intptr_t fd1, fd2, m1, m2;

/* workspace string for memfd names */
memcpy((void *)0x200000000100UL, "syz-mseal\0", 10);

/* fd1: first memfd, mapped at 0x21da8000 */
fd1 = syscall(__NR_memfd_create,
(uint64_t)0x200000000100UL, (uint64_t)1UL);
if (fd1 < 0)
return;

m1 = syscall(__NR_mmap,
(uint64_t)0x21da8000UL, (uint64_t)0xdd000UL,
(uint64_t)8UL, /* PROT_SEM */
(uint64_t)0x11UL, /* MAP_SHARED | MAP_FIXED */
(intptr_t)fd1, (uint64_t)0UL);

/* fd2: second memfd, mapped at 0x21da6000 (overlaps m1 at start) */
memcpy((void *)0x200000000100UL, "syz-mseal\0", 10);
fd2 = syscall(__NR_memfd_create,
(uint64_t)0x200000000100UL, (uint64_t)1UL);
if (fd2 < 0)
return;

m2 = syscall(__NR_mmap,
(uint64_t)0x21da6000UL, (uint64_t)0xdd000UL,
(uint64_t)8UL,
(uint64_t)0x11UL,
(intptr_t)fd2, (uint64_t)0UL);

/*
* Step 1: Partial seal on m1 range.
* Seals [0x21da8000 .. 0x21de5fff] -- a subset of VMA-A.
* Sets VM_SEALED (0x400000000000) on VMA-A.
*/
syscall(__NR_mseal, (uint64_t)m1, (uint64_t)0x3e000UL, (uint64_t)0UL);

/*
* Step 2: Seal spanning VMA-A (sealed) + VMA-B (not sealed).
* Range [0x21da6000 .. 0x21e15fff].
* -> vma_merge_existing_range() WARN fires.
*/
syscall(__NR_mseal, (uint64_t)m2, (uint64_t)0x70000UL, (uint64_t)0UL);
}

int main(void)
{
fprintf(stderr,
"============================================\n"
"repro_mseal_vma -- mm/vma.c:830 reproducer\n"
"Reporter: Antonius / Blue Dragon Security\n"
" https://bluedragonsec.com\n";
" https://github.com/bluedragonsecurity";
"============================================\n"
"Monitor: dmesg | grep 'WARNING.*vma\\.c:830'\n\n");

setup_workspace();

for (int iter = 0;; iter++) {
pid_t pid = fork();
if (pid < 0) {
perror("fork");
return 1;
}
if (pid == 0) {
trigger();
_exit(0);
}
int st;
waitpid(pid, &st, 0);
fprintf(stderr, "[iter %d]\n", iter);

if (iter % 5 == 0)
system("dmesg 2>/dev/null | grep -c 'WARNING.*vma\\.c:830' "
"| xargs -I{} sh -c "
"'[ {} -gt 0 ] && "
"echo \"[+] WARNING triggered {} times total\"'");
}
return 0;
}

Attachment: dmesg_linux_kernel_7_rc5.png
Description: PNG image