Fixing the Linux Kernel: Upstream Memory-Safety Contributions
The same automated research pipeline that audits npm packages now reads kernel C — and has landed memory-safety fixes in the mainline Linux kernel, each maintainer-reviewed and shipping to stable. Here's what merged, and how.
Finding a bug is the easy half. The hard half — the half that actually proves a security pipeline works — is getting a maintainer to accept your fix into the code that ships to everyone.
Over the past few weeks, 0sec’s automated security research has done exactly that in the place where the bar is highest: the mainline Linux kernel. Not a fork, not a write-up, not a “potential issue” filed into a tracker. Real patches, reviewed by the subsystem maintainers, merged into Linus Torvalds’ tree, and flowing out to the stable trees that distributions ship.
Every one carries the same line in its permanent git history: “Found by 0sec automated security-research tooling.”
What landed
| Subsystem | Bug class | Status | Commit |
|---|---|---|---|
| NFC (digital layer) | stack buffer overflow | merged to mainline + stable | b3d780a2 |
| Bluetooth (LE Audio CIS) | use-after-free | merged to mainline + 4 stable trees | bfea6091 |
| TIPC (crypto) | use-after-free | merged to mainline | bda33488 |
| mac802154 (802.15.4 crypto) | missing copy-on-write | accepted upstream, landing | 84a04eb5 |
| NFC (LLCP) | TLV integer underflow + OOB read | merged to mainline | ed85d4cb |
Each links to the real commit — verifiable in the kernel’s own git, with our authorship attached.
How the pipeline gets there
The kernel work runs on the same principle as our package research: read the source, trace the data, prove the bug, then propose the minimal correct fix. The difference is the rigor the kernel community (rightly) demands before anything merges:
- Source analysis surfaces a candidate — an attacker-influenced length feeding a copy, a pointer used after a concurrent free, a crypto path missing a guard its sibling already has.
- Verification before sending. Every patch is generated byte-exact from a real tree, apply-checked, and compile-clean. Where a bug has a public reproducer, we confirm the fix against it — for the NFC overflow, that meant a
#syz testrun on syzbot’s reproducer, which came backTested-by: syzbotbefore the patch ever reached a maintainer. - Upstream review. Maintainers and reviewers — at Intel, Red Hat, and across the kernel community — reviewed the patches. The TIPC fix carries three independent
Reviewed-bytags; the NFC and 802.15.4 fixes carry maintainer review from Intel.
The TIPC one is a good example of how these get found: the encrypt path had already been fixed for a use-after-free during network-namespace teardown — but the decrypt twin was left unguarded. That’s incomplete-fix variant analysis: take a known, patched bug and ask whether its mirror image was missed. It was.
Being honest about severity
These are memory-safety and robustness fixes — use-after-frees and overflows that, in their realistic threat models, mean a crash (denial of service) or, at most, a corruption primitive that no one has weaponized. They are not remote code-execution exploits, and we don’t dress them up as such. No CVEs are attached yet; the kernel’s CVE process assigns those on its own schedule, and we won’t claim numbers we don’t have.
What they are is the genuine, verifiable bar: an automated research pipeline that doesn’t just produce findings, but produces fixes that the maintainers of the Linux kernel chose to merge — five of them, across four different subsystems, in a few weeks. That code now rides into the kernel at the heart of billions of devices.
That’s the proof that matters: not “we found something,” but “it’s in the tree, with our name on it.”