[+] Run from exp@192.168.1.82, uid=1000 (unprivileged), 2026-05-02

Linux 7.0.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 22 16:06:43 UTC 2026

build rc=0

[*] pre-seal contents:    "BEFORE-SEAL"
[*] direct F_ADD_SEALS F_SEAL_WRITE blocked: Device or resource busy (expected EBUSY)
[*] after F_ADD_SEALS EXEC: seals=0x3e [SHRINK GROW WRITE FUTURE_WRITE EXEC ]
[*] post-seal via fresh RO map: "AFTER-SEAL!"
[*] new PROT_WRITE mmap correctly blocked: Operation not permitted

[+] CONFIRMED: F_SEAL_WRITE reported set, yet the pre-existing
    PROT_WRITE/MAP_SHARED mapping is still live and writes are
    visible to fresh readers via the page cache.
    A privileged consumer that handshakes on F_GET_SEALS sees
    a mutable buffer.

run rc=0

Interpretation:
  - Honest path (F_ADD_SEALS F_SEAL_WRITE) correctly returns -EBUSY
    when a writable mapping exists — that gate is wired up.
  - Implicit path (F_ADD_SEALS F_SEAL_EXEC on a memfd with i_mode 0111)
    OR-injects F_SEAL_WRITE | F_SEAL_FUTURE_WRITE | F_SEAL_SHRINK |
    F_SEAL_GROW into the seal state WITHOUT calling
    mapping_deny_writable() / memfd_wait_for_pins().
  - Result: F_GET_SEALS returns 0x3e (includes F_SEAL_WRITE) yet the
    pre-existing PROT_WRITE/MAP_SHARED mapping remains live; writes
    through it land in the page cache and are visible to fresh
    PROT_READ/MAP_SHARED readers.
  - A privileged consumer (e.g. systemd-journald, snap, Chromium IPC)
    receiving the sealed memfd via SCM_RIGHTS and trusting F_SEAL_WRITE
    for content immutability is fooled.