snailsploit[$]
⌘K live
linux kernel
mainline
2025–2026
5 mainline patches
standard maintainer process
backports where applicable

kernel
contributions.

Five vulnerabilities found, fixed, and merged through the standard maintainer process. io_uring/zcrx (a user_ref race producing a double-free that escalated to an OOB write), net/tipc, Bluetooth, RDMA/ionic, and net/rtnetlink. No drama, no out-of-tree patches — just the slow path: report, debug, propose, iterate, merge.

01 · patches
Subsystem · vulnerability class · ship status. All five upstream.

5 mainline patches.

01io_uring/zcrx
user_ref race → double-free → OOB write
Mainline 7.0-rc1 · backports 6.18.16 + 6.19.6
02net/tipc
tipc_mon_peer_up UAF vs bearer teardown
Mainline
03Bluetooth
hci_conn UAF in create_big_sync / create_big_complete
Mainline
04RDMA/ionic
Unbounded node_desc sysfs read via %.64s
Mainline
05net/rtnetlink
ifla_vf_broadcast stack infoleak (zero init missing)
Mainline
02 · approach
Kernel work is its own sub-discipline. Different cadence, different etiquette, different success criteria.

how kernel work goes.

Read the syzbot reports

Most of these started by reading what syzbot already found and looking at the surrounding subsystem with a bit more care. The kernel community has the world's best fuzzer pointing at it 24/7. The job is filling in the part the fuzzer can't reason about — the lifecycle and protocol logic between crashes.

Reproduce in a VM, not on hardware

QEMU + kernel-under-test + a minimal initramfs. Faster iteration, no kernel panics on the development laptop, easier to share a reproducer with the maintainer.

Patch first, writeup later

If you have a patch ready when you report, the maintainer's job is review instead of triage. The fix lands faster and you don't end up arguing about scope with someone who has 200 other things to do.

No security theater in commit messages

Commit messages describe what the patch does and why, not how cool the bug is. The maintainer cares about the diff, not the marketing.