Post cover image
Bug Reproduced and Analysis

August 7, 2026

I Gave an Open-Weight Model a Linux Kernel Bug(CVE-2026–64564).

What a public disclosure, a detailed technical write-up, and an open-weight coding model can produce when the target is a complex kernel…

By Deena

4 min read

I Gave an Open-Weight Model a Linux Kernel Bug(CVE-2026–64564). It Got Surprisingly Close to an Exploit

What a public disclosure, a detailed technical write-up, and an open-weight coding model can produce when the target is a complex kernel lifetime bug.

When SCTPhantom was disclosed as CVE-2026–64564, I approached it as an independent reproduction exercise. My starting material was the public oss-security post, Zhuque Lab's full write-up, and the affected Linux SCTP source, plus some X posts 1 , 2.

The question was simple: how far could I get by pairing those materials with an open-weight model?

The answer was farther than I expected. It did not produce a portable, one-click exploit, but it helped turn a dense protocol-lifetime bug into a PoC that was already approaching exploit territory.

The write-up supplied the map

SCTPhantom is a use-after-free in SCTP Dynamic Address Reconfiguration. The bug depends on two addresses having different roles: the IPv4 source address, S, and the Address Parameter, L, used to select the transport cached in asconf->transport.

As Zhuque Lab explains in its root-cause analysis, Linux validates a DEL-IP operation against S, while later code continues to trust the transport selected through L. That makes the following ordered ASCONF sequence significant:

[ Address Parameter L ] [ DEL-IP L ] [ DEL-IP 0.0.0.0 ]

DEL-IP L removes the cached transport. The wildcard DEL-IP then reuses the stale pointer in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(). The association can survive with primary_path and active_path still pointing at the removed object.

The RCU boundary is important. A stale pointer immediately after deletion is not yet proof of a post-free access. Zhuque's surviving-UAF section describes letting ASCONF processing return, waiting for the RCU callback, and reaching the dangling path from a later socket operation. That distinction gave me a concrete success condition for the PoC.

None

Where an open-weight model helped

I used an open-weight coding model — Kimi K3 in this experiment — as a fast kernel pair programmer rather than as an exploit oracle. I gave it the disclosure, the write-up, the relevant SCTP functions, compiler errors, and the output from each test run. Its most useful contributions were mechanical:

  • turning the three-parameter ASCONF sequence into a packet-building routine;
  • tracing which association and transport fields had to remain reachable;
  • mapping target-specific structures against the Ubuntu kernel's BTF data;
  • comparing crashes with the expected post-RCU path;
  • keeping a running list of assumptions when a reclaim attempt failed.

The productive loop was short: ask for one change, compile it, run it, return the literal result, and revise the next step. The model could suggest why a state transition or allocation missed, but the VM result decided whether that explanation survived.

Porting the PoC to Ubuntu

Porting the PoC to Ubuntu 26.04 with the 7.x kernel was where the model became most useful. The ASCONF trigger itself did not change, but the exploitation scaffolding did. I had the model treat the earlier target as a reference and build an Ubuntu-specific delta: derive the link-time K_* symbols from /boot/System.map, check structure layouts against /sys/kernel/btf/vmlinux, update the PCPU_CURRENT offset and five-level-paging address tests, and review Ubuntu's kernel configuration instead of carrying old assumptions forward.

The first reclaim attempts also showed that the previous spray parameters did not transfer cleanly. It helped reduce that problem to a tighter loop: adjust the reclaim choice and spray volume, rerun from a fresh boot, and keep only changes supported by the logs. The protocol sequence was portable; the heap layout and reclaim behavior were specific to the Ubuntu build.

The trigger became surprisingly small

The local PoC grew into a large, target-specific C file, but the protocol sequence at its center remained compact.

p=p16(p,PARAM_IPV4); p=p16(p,8); p=p32(p,htonl(L));               // Addr Param L (= chunk->transport)
p=p16(p,PARAM_DEL_IP); p=p16(p,16); p=p32(p,htonl(1));
p=p16(p,PARAM_IPV4); p=p16(p,8); p=p32(p,htonl(L));               // DEL-IP L (frees asconf->transport)
p=p16(p,PARAM_DEL_IP); p=p16(p,16); p=p32(p,htonl(2));
p=p16(p,PARAM_IPV4); p=p16(p,8); p=p32(p,0);                       // DEL-IP 0.0.0.0

Those lines encode the identity mismatch described in the write-up: select transport L, delete L, then process the wildcard address. The difficult part was everything around them — building a stable multihomed association, preserving it through RCU release, reducing allocator noise, and distinguishing a real reclaim from a crash caused by unrelated state.

None

From trigger to almost-exploit

Once the post-RCU access was repeatable, the write-up provided a second roadmap. Zhuque's chain uses a pg_vec reclaim to disclose a direct-map address, turns the reclaimed transport into a small kernel-read primitive, recovers the KASLR slide from the fixed IDT mapping, and finally reaches commit_creds() through a controlled object graph.

The model helped translate that chain into code and target-specific checklists. It was particularly good at tracking offsets, packet fields, and the relationship between the reclaimed sctp_transport and the fake objects referenced from it. The resulting PoC was close to an exploit, but reliability still depended on details the model could not guess: exact structure layouts, symbol baselines, allocator behavior, CPU locality, and the timing of the RCU callback.

That is also where the experiment became most instructive. Public technical detail dramatically reduces the distance between a CVE description and working code. An open-weight coding model reduces the mechanical cost again. Neither removes the need for careful validation, especially when a single successful run can hide a bad assumption.

What I took away

The impressive part was not that an open-weight model could write C. It was that a well-documented evidence chain gave the model enough structure to make useful progress on a difficult kernel bug. The write-up supplied the invariants; the model accelerated translation and iteration; the test environment separated plausible code from code that actually reached the intended state.

SCTPhantom has been fixed upstream in 9b2854f86f0b. My reproduction stayed in a controlled lab, and this article intentionally stops short of publishing a turnkey exploit. Even so, getting from a public CVE and write-up to a near-exploit PoC with an open-weight model was a useful measure of how quickly the economics of vulnerability reproduction are changing.