# FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 2 of 2)

Unprivileged RTM_GET routing message with oversized RTAX_AUTHOR sa_len overflows kernel stack sockaddr_storage, chained with stack leak to escape FreeBSD jail to root.

- Payout: Research
- Severity: high
- Program: FreeBSD
- Found by (vendor credit): Adam Crosser of the Praetorian Labs team
- Write-up by: Praetorian
- Disclosed: 2026-07-06
- CVE: CVE-2026-3038
- Write-up quality: 9/10
- Original: https://www.praetorian.com/blog/llm-kernel-exploit-development/
- Library page: https://bugbountylibrary.com/r/blog%3Apraetorian-com-blog-llm-kernel-exploit-development
- Tags: area:oss domain:oss impact:internal-access impact:privesc impact:rce kind:research platform:research sev:high tech:linux technique:chained technique:source-review vuln:info-disclosure vuln:memory-corruption vuln:privilege-escalation

**Target:** FreeBSD kernel routing socket subsystem (rtsock_msg_buffer)
**Root cause:** A user-controlled sa_len field in an RTAX_AUTHOR sockaddr allows up to 127 bytes of attacker data to overflow a sockaddr_storage buffer on the kernel stack in rtsock_msg_buffer(), reachable unprivileged via RTM_GET.
**Steps:**
1. Trigger a separate ioctl handler that copies more data to userspace than intended, leaking kernel stack contents including the stack canary and a kernel text return address at a known offset from kernel base.
2. Compute kernel base and ROP gadget/symbol addresses from the leaked return address.
3. Construct an RTM_GET routing message with an oversized RTAX_AUTHOR sockaddr with `sa_len` set to 255.
4. Place the leaked canary at the correct offset in the 127-byte overflow payload, zero saved callee-save registers, and overwrite the return address with a ROP chain that clears SMEP/SMAP in CR4 and pivots to userspace shellcode.
5. Shellcode releases the read-side critical section lock, sets cr_uid/cr_ruid to 0, sets cr_prison to prison0, points directory refs to rootvnode, restores saved CR4, and returns via doreti.
**How found:** Part one used Claude Code/Opus 4.6 to build a database of known vulnerability patterns, generate CodeQL and semgrep rules for variant hunting, and triage candidates against a KASAN-instrumented FreeBSD VM feedback loop; the rtsock sa_len overflow surfaced from that variant hunt.
**Exploitation:** From inside a VNET jail, leak stack canary and kernel text pointer via an over-copying ioctl, then send RTM_GET with oversized RTAX_AUTHOR sa_len=255 to overflow rtsock_msg_buffer's stack buffer. ROP clears CR4 SMEP/SMAP bits and pivots to ring-0 shellcode that zeroes credentials, reassigns prison to prison0, and repoints directory vnodes to rootvnode, yielding a root shell on the host with full filesystem access.
**Escalation:** Chains an info-leak primitive (canary + KASLR defeat) with the stack overflow to bypass stack canary, KASLR, SMEP and SMAP, escalating from unprivileged jail process to host root.
**Insight:** VNET jails expose large swaths of legacy networking code written assuming only trusted host root would call it; audit rtsock and other pre-jail networking handlers for user-controlled length fields (sa_len) copied into fixed kernel stack buffers, and pair with over-copying ioctl handlers that leak stack canaries and text pointers.