kernel-security-learning: a curated map of Linux kernel exploit writing

A reading list organised by primitive, not by year

kernel-security-learning is a collection of links about kernel security, and the repository description lists the scope precisely: CTF kernel pwn, kernel exploit, kernel fuzz and kernel defense papers, kernel debugging techniques and kernel CVE debugging. The primary language is recorded as C, but the top-level entries show what the repository actually is: a README, a CVE directory, a debug_technique directory and a paper directory.

There is no build system, no library and no test suite. The value is in the curation, and the curation has a shape that is worth describing because it differs from a plain link dump.

The CTF section opens with a sequence of environment setup and demonstration entries, and the entries that follow move through the classic primitive families: null dereference and stack overflow first, then use-after-free on driver objects, double fetch, arbitrary read and write, and the privilege escalation routes that build on them. There are entries on ret2dir, on bypassing the hardened slab freelist protections, on cross-cache attacks against the cred structure, and on constructing arbitrary frees through the poll_list object. The later entries are labelled as exploit tricks rather than walkthroughs, which is a signal about depth.

The paper section runs chronologically from 2014 to 2023 and each entry is a named system, from ret2dir through FUZE, KEPLER, SLAKE, KOOBE and ELOISE up to PSPRAY and AlphaEXP. Reading the titles in order shows the field narrowing from one bypass technique to a general theory of heap object layout.

The organizing idea is the primitive rather than the calendar, which is why the list is worth more than a pile of bookmarks.

Every paper entry carries a note and often a tool link

The paper entries are not bare citations. Each one lists a venue and year, a link to the paper, and then annotation links, some of which point to a Chinese-language reading note written by the maintainer and some of which point to a second explainer on a different site. Several entries also carry a tool link to a separate GitHub repository, and those repositories are the most actionable part of the list.

FUZE, KEPLER, SLAKE, KOOBE and ELOISE each have a tool entry, and they cluster around one idea: automating the search for an exploit primitive. ELOISE is titled a systematic study of elastic objects in kernel exploitation, which is a phrase worth pausing on, because elastic objects are the ones whose contents can be manipulated to make an exploit reliable across allocator states. KOOBE targets out-of-bounds writes, KEPLER targets control-flow hijacking primitives, SLAKE targets slab manipulation, and FUZE targets use-after-free bugs. SysScope, GREBE and Kasper appear later, with SysScope focused on high-risk security impacts of fuzzer-exposed bugs, GREBE on unveiling exploitation potential for kernel bugs, and Kasper on scanning for generalized transient execution gadgets.

Two entries stand out for being about reliability rather than exploitation itself. KHeaps examines what makes Linux kernel exploits reliable, and PSPRAY is a timing side-channel based heap exploitation technique, which is a different model entirely since it does not need a memory corruption primitive at all.

The list also includes defenses, since the scope statement mentions kernel defense papers. That matters for anyone doing vulnerability research rather than only CTF, because the defensive papers give the shape of the mitigations a defender would deploy.

The CTF entries move from setup to arbitrary read and write

The first three CTF entries form a small course rather than three unrelated writeups. The first is about environment configuration, the second demonstrates a null dereference and the third demonstrates a stack overflow in the kernel. Reading them in that order means you set up the debugging and exploitation environment before you see the two simplest bug classes applied to it.

After that come competition writeups tied to named events, and the events cluster around 2017 and 2018: a core stack overflow challenge, a driver use-after-free, a double fetch bug, a solid_core challenge granting arbitrary read and write, and a StringIPC entry that works from arbitrary read and write through to privilege escalation in three different ways. The naming makes the progression legible. Each writeup is one more step along a chain that starts with a memory bug and ends with a root shell.

Later entries cover the mechanisms that get you there. There is a klist race use-after-free with pipe heap spraying, a double fetch on a gnote device, a userfaultfd entry from the Balsn CTF, a heap spraying entry on sendmsg and msgsend, a privilege escalation entry that goes from arbitrary read and write to escalation in four ways, an uninitialized stack variable entry, and a ret2dir entry.

The maintainer's own two exploit trick entries are the ones written outside competition context. One covers using the msg_msg structure to achieve arbitrary read and write, and the other covers a cross-cache attack against the cred structure with the corCTF 2022 case of castaways as the reference. The cred structure is the point of that second entry, since overwriting a credential in the right cache is how a kernel bug becomes root.

Debugging notes and CVE material live in their own directories

The top-level entries include a debug_technique directory and a CVE directory alongside paper/. The README visible here does not describe their contents, but the names tell you what the maintainer considers separate from the reading list, and the structure implies two additional bodies of work beyond curated links.

The debug_technique directory is the one that would change your workflow rather than your understanding. Kernel debugging has a set of techniques specific to the environment, and the fact that they are collected separately from the papers suggests they are written as procedures. Since the description lists kernel debugging technique as a distinct scope item alongside exploit writing, fuzzing and defense, the maintainer treats it as a first-class activity rather than an appendix.

The CVE directory follows the same pattern. CVE debugging is a distinct discipline from exploit development, because you are working from a patch or an advisory and reconstructing the bug rather than hunting for one. A directory that holds that work separately from the papers keeps the two from mixing.

For a user, this layout tells you where to look for a specific need. Reading a field survey of heap exploitation is a paper task, a technique to reproduce a bug on a given kernel is a debug_technique task, and understanding a specific advisory is a CVE task. The repository does not claim to have an index across them, so the README remains the main entry point.

A third party's blog links are the weakest part of the map

Almost every CTF entry in the list points at a blog platform rather than at a paper, and several of those links are hosted on a single author's personal space. The entries are all in Chinese, which narrows the audience considerably even though the underlying techniques are universal, and the pages are hosted on services where links rot.

This is the honest limitation of the repository. It is a personal curation with a maintenance promise of continuing updates, and a personal curation ages in a way a tool does not. The last push was on 2026-10-10, which tells you the links are being kept alive, but it does not tell you that the linked writeups still match the kernels in use today.

The paper entries are more durable, because a published paper and its PDF do not disappear. The tool links are in the middle, since they are GitHub repositories that can be archived, unmaintained or left depending on their authors.

The repository licence is recorded as unknown, which matters if you plan to copy content out of it. A list of links is a thin case for copyright, but a maintainer's own writeup in a debug note is a different matter from a link to a published paper.

None of this makes the map bad. It makes it a map with a shelf life, and the way to use it well is to treat each entry as a starting point you verify rather than a reference you cite.

Editorial conclusion

kernel-security-learning is worth bookmarking if you are working on Linux kernel exploitation, privilege escalation research or a kernel CVE and want a map of which primitive families exist and which papers argue about them. It is not a codebase, a fuzzing harness or a debugging tool you can run, so it will not speed up an actual exploit session on its own. Before you rely on it, verify three things yourself: that the linked tools such as FUZE, KEPLER, SLAKE, KOOBE, ELOISE, SyzScope, GREBE and Kasper still build against a current kernel, since those are third-party repositories the list only points at, that the notes attached to the newer papers still match the paper PDFs after revisions, and that the CVE directory reflects the advisories you are actually chasing, because a list of links ages quietly while the underlying bugs get patched.

Frequently asked questions

Official sources

1. bsauce/kernel-security-learning on GitHub
2. Issues
3. README