fcrypt mismatch, nscd cache, and root in ~90 minutes."/> fcrypt mismatch, nscd cache, and root in ~90 minutes."/> dirty frag field notes: from a patched server that was "safe" :: shaurya
← blog the short version
i got root on my university's shared login server. not because the sysadmins were asleep or because the box was some ancient forgotten machine. they were actually fast. they had read the CVE writeups, blocked the recommended kernel crypto interface, disabled unprivileged user namespaces, tested the public PoC, watched it fail, and moved on.
reasonable response tbh. the problem is that public PoCs are not truth oracles. they only tell you one thing: this exact code path, as written, did not work on this exact run. that is not the same as "the system is safe".
so i put DeepSeek-V4-Flash in a boring shell feedback loop on a Lightsail replica:
textcopy<br>compile -> run -> read error -> patch -> repeat
about 90 minutes later, the exploit worked on the real server. i reported it, and they patched it properly within an hour. this is mostly a field-trip blog on the whole journey to get root access and how cheap intelligence has gotten if harnessed correctly.
the target
this was ssh1.iitd.ac.in, a shared login box for the electrical engineering department at IIT Delhi. my friend had gotten root on it last year when it was running Linux kernel 4 on Ubuntu 16. ancient era. this time it was not ancient anymore.
initial state:
thing<br>value
kernel<br>Linux 6.8.0-111-generic, built April 11 2026
distro<br>Ubuntu 24.04 LTS, glibc 2.39
user<br>normal student user, no sudo, no Docker/LXD group
user namespaces<br>kernel.unprivileged_userns_clone = 0
AF_ALG<br>blocked through modprobe rules
important bit: AF_ALG was blocked, but pcbc(fcrypt) was still registered in /proc/crypto. foreshadowing...
background, quickly
Dirty Frag is a Linux kernel privilege escalation from May 2026. it has two main paths: CVE-2026-43284 -> xfrm ESP path, and CVE-2026-43500 -> RxRPC path.
both get to a page-cache corruption primitive during kernel crypto work. the public exploit uses that to temporarily modify /etc/passwd, blank root's password, then su to root. very funny family of exploits.
AF_ALG is the kernel's userspace crypto socket API. most writeups said: block AF_ALG, block the algif modules, you're good until you patch. this is a really good patch as it stops the public poc from working.
first attempt
i first tried Copy Fail, mostly because it had dropped around the same time and looked like the obvious thing to test. it died immediately:
textcopy<br>socket(AF_ALG, ...) = -1 EAFNOSUPPORT
fair enough. mitigation worked.
then i tried Dirty Frag.
ESP path -> blocked because unprivileged user namespaces were disabled.<br>RxRPC path -> got further, because creating an AF_RXRPC socket caused rxrpc, fcrypt, and pcbc to auto-load. but it still failed at the checksum step because the public PoC expected to use AF_ALG.
at this point the obvious conclusion was:
textcopy<br>both cves blocked -> public poc failed -> server safe
most people will probably stop there. but pcbc(fcrypt) was still in /proc/crypto, so the question became: if the kernel can still use the algorithm internally, why is userspace AF_ALG the final blocker?
the loop
this is where deepseek v4 flash, the cheapest model known to mankind, did the useful work.
the loop was boring:
textcopy<br>compile -> run -> read stderr + dmesg + return code -> patch code -> repeat
i love boring loops coz they work and i can track them.
also slightly cursed realization: this is just control engineering. this semester i was studying ELL 225: Control Engineering. i did not expect any of that to make my prompting better, but it did.
LLM in a harness feels like a controller:<br>goal prompt -> setpoint<br>shell/tool environment -> plant<br>stderr/dmesg/tests -> sensor<br>code edits -> control input<br>repeated runs -> feedback loop.
what the agent found
1. public PoC fcrypt != kernel fcrypt
this was the actual turn. within about 9 minutes, the agent noticed that the fcrypt implementation in the public PoC did not match the kernel's pcbc(fcrypt-generic) implementation. different round structure. different key mixing. byte order weirdness.
i will be honest here, i had no idea about this and i was already far from my home waters. dipping my toes first time in cybersecurity.
2. byte order in fcrypt_user_setkey
on the Lightsail replica, the agent fixed the byte order in fcrypt_user_setkey so the userspace fallback matched the kernel schedule. small and boring but important fix.
3. POC_NO_UNSHARE
there was also a POC_NO_UNSHARE path already sitting in the codebase. using it got past the user namespace setup and moved the exploit from immediate failure to rc=3.
i feel stupid for not checking this myself first.
4. nscd
final blocker was nscd. on Ubuntu 24.04, nscd can cache passwd lookups. so even after the page-cache corruption modified /etc/passwd, PAM could still see the old cached root:x:0:0:......