{"id":48304227,"title":"Dirty Frag: a kernel zero-day vs. container and microVM sandboxes","points":2,"user":"ShivamNayak11","time":1779939818,"time_ago":"9 hours ago","type":"link","content":"

On May 7, Hyunwoo Kim (V4bel) disclosed Dirty Frag — two Linux kernel\nvulnerabilities (CVE-2026-43284 and CVE-2026-43500) that give unprivileged\nusers deterministic root on most Linux distributions shipped since 2017.\nMicrosoft confirmed active exploitation the next day.

We build declaw.ai — sandboxing infrastructure for AI agents, on Firecracker\nmicroVMs. We run untrusted code we don't write and can't predict, so when\nDirty Frag dropped our first question was: does our isolation boundary hold?\nWe tested it on a deliberately unpatched kernel. It held. Here's why.

The exploit is a page-cache write primitive: it tricks the kernel into\noverwriting the in-memory contents of any file (/usr/bin/su, /etc/passwd) and\ngives root. Fully deterministic, no race.

Why it matters for multi-tenant platforms: the page cache is shared across\nthe whole machine. Containers share the host kernel, and namespace isolation,\nseccomp, and dropped capabilities are all enforced by that kernel. A kernel\nexploit doesn't need to escape the container — it operates below the layer\nwhere container isolation exists. Same structural issue as Dirty COW (2016)\nand Dirty Pipe (2022). On the day a zero-day drops, before any patch exists,\nevery container-based sandbox sharing that kernel is exposed. Patching closes\nthe window after the fact; it can't close it in advance.

We ran the public PoC (ESP path, CVE-2026-43284) in two environments.

Test 1 — container sandbox (Docker, seccomp on, unprivileged uid=1001, host\nkernel 6.8.0): unprivileged user to root in under 2 seconds. Seccomp was\nactive but didn't help — the required syscalls were permitted by the profile.\nWith root we read /etc/shadow, host kernel boot params, and Docker overlay2\npaths.

Test 2 — Firecracker microVM (unpatched guest kernel, no seccomp, started as\nroot with full capabilities — intentionally MORE permissive than test 1). The\nexploit worked inside the guest, but every attempt to reach the host\nfailed: host kernel not visible, host processes invisible (the guest has its\nown kthreadd/kswapd), all host ports closed, only virtual block devices, no\nhost hardware identity. The page cache it corrupted belongs to the guest's\nown kernel, mapped to a bounded region of host memory via EPT.

The asymmetry is the point: the microVM started with more privilege than the\ncontainer and still couldn't reach the host. What matters isn't what\npermissions the software grants — it's whether the kernel is shared. To\nescape Firecracker you'd need a bug in the VMM (~50K lines of Rust) or KVM;\nGoogle's kvmCTF pays $250K for a guest-to-host escape and only one has ever\nbeen publicly demonstrated.

If you run untrusted code multi-tenant, the question for any isolation\nprovider: if code inside the sandbox becomes root, can it reach the host or\nother tenants? If the answer is "as long as we're patched" — that's the gap.

PoC: https://github.com/V4bel/dirtyfrag\nFull writeup (commands + output): https://declaw.ai/blog/dirty-frag-microvm-isolation","url":"item?id=48304227","comments":[],"comments_count":0}