Google's kernel-research repository ships kernelXDK, a modular toolkit for building, testing and studying Linux kernel exploits against lab-owned kernel images for authorized research.

Kernel exploit development has always been a fragmented discipline: a researcher typically assembles their own ad hoc mix of gadget finders, QEMU wrappers, debug scripts and offset databases before writing a single line of exploit logic. google/kernel-research, published under the name kernelXDK, is an attempt to consolidate that whole workflow into one coherent framework, released as an Apache-2.0 licensed C++ codebase under the google GitHub organization. The README is explicit that this is not an officially supported Google product and that the project is in a beta state, which tells you two things immediately: expect rough edges, and expect meaningful evolution in the component APIs.

The repository is organized as a family of cooperating components rather than a monolith. The centerpiece is libxdk, described as a work-in-progress Linux kernel exploitation kit containing the building blocks needed to construct exploits that can target various kernel versions. That phrase — building blocks targeting multiple kernel versions — is the architectural thesis of the whole project. Instead of hardcoding offsets and gadget addresses into a single exploit binary, libxdk is meant to consume target-specific data prepared by other components, so the same exploit skeleton can be retargeted across distro releases by swapping the data layer.

That data layer is kxdb_tool, a database builder that collects exploitation-relevant information — symbol addresses, ROP gadgets, stack pivots and structure field offsets — for multiple kernel targets, and which the exploit kit consumes to customize exploits per target. This separation of logic from target metadata mirrors what mature exploitation frameworks on other platforms have done for years, and it is the component defenders should understand best when reasoning about how a research toolkit differs from a one-shot weaponized exploit: the framework itself is inert without an accompanying target database built from kernel images the researcher supplies.

Feeding kxdb_tool is the job of image_db, a set of tools for downloading distribution kernel release files and extracting information from them. Combined with rop_generator, which produces ROP chains and stack pivots against Linux kernel images, the pipeline becomes clear: fetch a distro kernel, extract symbols and gadgets into a database, then generate the low-level chain primitives the exploit will need. Everything in this chain operates on files the researcher deliberately obtains; nothing in the README suggests remote targeting or automated acquisition from third-party systems.

The runtime side of the workbench is image_runner, a tool for running various kernel distributions with debugging support and custom kernel module compilation. This is essentially the lab harness: it lets a researcher boot the exact kernel version recorded in their kxdb_tool database, attach a debugger, and iterate on exploit code against a fully controlled guest. For anyone teaching kernel exploitation or reproducing public CVE writeups in a sandbox, this is the component that makes the rest of the kit safe and practical to use, because the blast radius is a disposable virtual machine.

The most research-specific piece is xdk_device, a kernel module living under third_party/kernel_modules/xdk_device that simulates vulnerabilities in the kernel, tracks function calls and tests exploitation primitives. Its existence reframes the toolkit from a purely offensive-convenience project into a genuine research instrument: by synthesizing controllable bug primitives — a use-after-free, an overflow, a refcount error, whatever the module models — a researcher can exercise each stage of an exploit chain independently of any real CVE. That is the classic methodology behind Mitnick-era training ranges and modern pwn-college style courses, brought into a versioned, database-driven framework.

Documentation lives at xdk.dev, which the README describes as providing setup guides, an API reference and — notably — guidance on porting existing exploits into the framework. That last item is a strong signal about intended audience and lifecycle: the authors expect practitioners to migrate their private, one-off exploit code onto libxdk abstractions, which in turn implies the library exposes primitives like object spraying, heap grooming, privilege escalation stubs and post-exploitation stabilization as reusable calls. Each subdirectory carries its own README.md with deeper detail, so the top-level document functions as a map rather than a manual.

Operationally, the authorized use case is straightforward and worth stating plainly: everything here belongs in a lab where the researcher owns the kernel images being targeted, whether that means reproducing a public vulnerability for mitigation validation, teaching exploit-development fundamentals with xdk_device, or studying how kernel hardening options like CONFIG_SLAB_FREELIST_RANDOM or control-flow integrity change gadget availability across versions. Pointing any of this machinery at systems you do not own or lack written authorization to test would be both illegal and a misuse of the toolkit's obvious design intent.

From a defensive perspective, the existence of a well-structured, version-aware kernel exploitation SDK is a useful threat-model input rather than cause for alarm. Frameworks lower the skill floor for Researchers in controlled settings, but they equally lower the effort for defenders to build regression tests: the same kxdb_tool databases that feed exploits can diff a patched kernel against a vulnerable one to verify that a gadget or offset truly disappeared after remediation. Blue teams running hardened distro kernels can also use the pipeline to audit how much exploitable surface their specific build configuration actually exposes.

The bug-reporting section of the README asks for OS, compiler toolchain and target kernel image details, and candidly warns that fixes may be slow or may not happen at all while the team focuses on core development. At roughly 93 stars, the project is young and clearly still finding its audience, but the component decomposition, per-component documentation and dedicated documentation site suggest a serious long-term engineering effort rather than a conference-artifact dump. For kernel security researchers who have maintained their own scattered scripts for years, kernelXDK is worth watching as it matures.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Inside msynth: how lookup tables and program synthesis tame MBA obfuscation


• wolfssh for embedding SSHv2 servers and clients in constrained systems


• Inside p0tools: how googleprojectzero publishes its research scraps and small utilities