# Kernel-Exploit-Dojo: a technique-indexed archive of 180+ Linux kernel CTF challenges > Kernel-Exploit-Dojo collects Linux kernel pwn challenges from 2020 onward, each with distribution files, exploit code and a writeup, indexed by bug class and final technique. It is a study archive for CTF players, not a toolkit. **mito753/Kernel-Exploit-Dojo** — CTF kernel exploitation notes, PoCs, exploits, and writeups. - Repository: https://github.com/mito753/Kernel-Exploit-Dojo - Stars: 565 · Forks: 72 - Language: C - License: not declared - Published: 2026-09-20 · Updated: 2026-09-20 · Language: en - Canonical page: https://hysenlabs.com/projects/mito753-kernel-exploit-dojo ## What Kernel-Exploit-Dojo actually is This repository is a curated archive of more than 180 Linux kernel exploitation CTF challenges, organized by bug class, exploitation primitive, final technique, difficulty, and solve count. Each challenge directory is meant to hold the original distribution files when available, the exploit code, and a technical writeup. The README calls it a practice-oriented archive for learning Linux kernel exploitation through CTF challenges, and the name is deliberate: "Dojo" means a training place. The intended reader is someone who already has a CTF kernel pwn habit. The topics list reads like a syllabus: UAF, pipe_buffer, msg_msg, modprobe_path, cred overwrite, kernel ROP, KPTI, SMAP and SMEP bypass, userfaultfd, Dirty Pipe, eBPF, QEMU. If none of those terms mean anything to you, the archive will not teach you the prerequisites; it assumes you can read a kernel module and a QEMU launch script. The scope is historical as well as current. Year folders run from 2020/ through 2026/, and the README notes that year folders are based on the actual event date, not necessarily the year in the CTF name. That matters when you are hunting for a specific competition: a 2026 event can live in 2026/ even if the branding says otherwise. ## How the index is built: bug, primitive, final technique The navigation model is the interesting design choice here. The top-level Challenge List is a table with columns for CTF, challenge, status, difficulty with solve count, bug, primitive, and final technique. A row might read: CakeCTF 2022, welkerme, solved / writeup, Very-Easy (75), kernel calls user function pointer, run user code as kernel, CC(PKC(0)). Another: ADDA CTF 2022, Kernauth, solved, Easy (11), TOCTOU race, struct cred overwrite, cred overwrite / commit_creds(). That three-column split is what separates this from a plain writeup dump. The bug column names the defect (kmalloc-1024 UAF, OOB write, stack buffer overflow, missing copy_from_user / copy_to_user). The primitive column names what the defect gives you (pipe_buffer reclaim, kernel read/write, kernel stack ROP, AAR/AAW). The final technique names where the exploit lands (modprobe_path overwrite, cred overwrite, GOT overwrite, QEMU monitor memory dump). A separate TECHNIQUES.md file exists for technique-based navigation, and the README points to it directly. So there are two entry points: chronological through the year folders, or technique-first through the index. The difficulty labels are explicitly subjective. The README states that difficulty is classified based on exploit complexity, required kernel knowledge, and solve count. Treat the parenthetical solve numbers as a rough proxy for how hard the community found the challenge, not as a measurement. One structural caveat visible in the table: the Status column is not uniform. Entries are marked "solved / writeup", "solved", or just "writeup". A writeup-only entry means the repository has notes but does not claim a working solve, so the completeness of any given directory varies. ## Cloning the archive and finding your first challenge There is no package, no installer, and no build system at the top level. The repository is a git checkout: the top-level entries are .gitignore, the year folders 2020/ through 2026/, README.md, TECHNIQUES.md, and assets/. You get the material by cloning it. ```bash git clone https://github.com/mito753/Kernel-Exploit-Dojo.git cd Kernel-Exploit-Dojo ls ``` You should see the year directories, README.md, TECHNIQUES.md and assets/ listed. From there, the README says the top-level Challenge List works as an index to each challenge directory, so the practical first step is to read the table and pick a row whose Bug and Final Technique match what you want to practice. Suppose you pick the easiest entry in the table, welkerme from CakeCTF 2022. Its directory path is given in the index as ./2022/CakeCTF_2022/Pwn_welkerme, so you navigate there and read the writeup before touching anything. ```bash cd 2022/CakeCTF_2022/Pwn_welkerme ls ``` What you find depends on the challenge: the README says each directory contains the original distribution files when available, exploit code, and a technical writeup. The "when available" qualifier is doing real work. If the distribution files are missing, you have notes and exploit source but no runnable target, and you will need to source the challenge files from the original CTF archive yourself. Running anything is a separate matter. The README's Disclaimer states the repository is for CTF learning and local lab environments only, that you should not run the exploits on production systems or systems you do not own, and that all examples are intended to be executed inside isolated QEMU/CTF environments. The QEMU topic tag confirms that expectation. This article has not run any of the exploits, and the repository does not document a single uniform run command across challenges, so expect per-challenge launch scripts rather than one entry point. ## Where the archive is thin, and where it is the wrong tool The first limitation is stated by the project itself: distribution files are included "when available". That is not a minor footnote. A kernel pwn writeup without the vulnerable module, the kernel image, and the filesystem image is a reading exercise, not a reproduction. For any challenge you care about, check the directory contents before assuming you can rebuild the environment. The second is the licence. The repository metadata carries no licence identifier, and the README does not discuss one. For personal study that is usually a non-issue. If you plan to copy exploit code into your own repository, into training material, or into anything distributed, you have no stated permission to rely on. That is a factual gap, not a legal conclusion; if it matters to you, ask the maintainer. The third is the nature of the content. Kernel exploits are version- and configuration-specific by design. A technique that works against one CTF kernel with a particular config, KASLR setting and SMEP/SMAP state may not transfer to a different target, and the writeups are tied to their original challenge environments. This is not a library you can import. It is a set of worked examples. Finally, consider what you are actually optimizing for. If you need a maintained exploitation framework with a stable API, this is the wrong repository: there are no releases, no tagged versions, and no build artifacts. If you need a general introduction to Linux kernel internals, the archive assumes that knowledge rather than teaching it. It is strongest precisely where it is narrow: as a lookup table from "I want to practice pipe_buffer abuse" to "here are the challenges where that was the intended path". ## How it compares to a plain writeup blog The obvious alternative is a personal CTF writeup blog or a wiki-style collection of posts. The difference is the indexing. A blog is chronological: you read whatever the author published most recently, and technique-based search means grepping prose. Kernel-Exploit-Dojo inverts that. The Challenge List is a table whose columns are bug class, primitive and final technique, so you can scan for every entry that ends in modprobe_path overwrite and work through them in order of difficulty. A second alternative is a challenge-hosting platform that keeps the original files and a scoring environment. That gives you a runnable target and a flag, but not the author's reasoning. This repository gives you the reasoning and, when available, the files, but no hosting and no guarantee the environment still builds. The third comparison worth making is against the original CTF archives themselves. Those are authoritative and complete for their own event, but they are organized by competition, not by technique. If you want to study one primitive across five years of challenges, the original archives force you to know in advance which events used it. The technique index here is the thing that saves that time, and it is the main reason to use this repository rather than going straight to the source archives. ## Maintenance, licensing and what a checkout costs you The repository is not archived, and the last push was on 2026-09-17. That is recent enough that the year folders extend through 2026 and include events such as D^3CTF 2026, MntcrlCTF 2026, DEF CON CTF Qualifier 2026, 0xFUN CTF 2026 and THJCC CTF 2026. There are no releases, so there is no version to pin and no upgrade path to plan. "Upgrading" means pulling the default branch. The cost of keeping a checkout current is therefore low in mechanism and non-trivial in size: it is a git repository of writeups, exploit source, and binary distribution files across seven year folders. If you only care about one technique, a sparse checkout or a shallow clone is a reasonable way to avoid pulling material you will not read. The repository does not document either, so that is a general git technique rather than a project feature. Licensing is the open question. No licence identifier appears in the repository metadata, and the README does not mention terms of use beyond the Disclaimer, which restricts where the exploits may be run rather than how the content may be reused. The Disclaimer is explicit that the material is for CTF learning and local lab environments only and that you must not run the exploits on production systems or systems you do not own. Read that as the operative constraint on use, and treat the absence of a licence as a reason to ask before redistributing anything from the archive. ## Conclusion Kernel-Exploit-Dojo suits CTF players and self-directed learners who already read kernel C and want a technique-first index of pipe_buffer, msg_msg and modprobe_path challenges, plus the distribution files and exploits that go with them. It is not for anyone who wants a maintained toolkit, a tested build, or a licence they can rely on: the repository states no licence and ships no releases. Before you clone, check the Challenge List and TECHNIQUES.md to confirm the specific challenge you care about is marked solved or writeup, open its directory to see whether the original distribution files are actually present, and read the Disclaimer; every exploit is meant to run inside an isolated QEMU environment, and the README says not to run them on systems you do not own. ## FAQ ### What is Kernel-Exploit-Dojo? It is a curated archive of more than 180 Linux kernel exploitation CTF challenges, organized by bug class, exploitation primitive, final technique, difficulty and solve count. Each challenge directory is intended to contain the original distribution files when available, exploit code and a technical writeup. ### Is Kernel-Exploit-Dojo safe to run, and where should the exploits be executed? The README's Disclaimer states the repository is for CTF learning and local lab environments only, that the exploits must not be run on production systems or systems you do not own, and that all examples are intended for isolated QEMU/CTF environments. ### What licence does Kernel-Exploit-Dojo use? No licence identifier is given in the repository metadata, and the README does not state licence terms. The only usage constraint documented is the Disclaimer, which limits the material to CTF learning and local lab environments. ### How do I find a challenge by exploitation technique rather than by year? Use the top-level Challenge List, whose columns include Bug, Primitive and Final Technique, or the separate TECHNIQUES.md file that the README points to for technique-based navigation. ### Does Kernel-Exploit-Dojo include the original challenge files? The README says each challenge directory contains the original distribution files when available, along with exploit code and a writeup. Because of that qualifier, some directories may have notes and exploit source without the runnable target files. ## Sources - [Issues](https://github.com/mito753/Kernel-Exploit-Dojo/issues) - [mito753/Kernel-Exploit-Dojo on GitHub](https://github.com/mito753/Kernel-Exploit-Dojo) - [README](https://github.com/mito753/Kernel-Exploit-Dojo/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mito753-kernel-exploit-dojo