Linux Kernel MCP Servers

A suite of 8 Model Context Protocol (MCP) servers providing AI-assisted tooling for Linux kernel development. 72 tools covering the full kernel development lifecycle.

MCP is an open, model-agnostic protocol. These instructions cover setup with the OpenAI Codex CLI; the same stdio entry points work with any other MCP-compatible client.

Servers

Server	Command	Tools	Description
Backport Tracker	kernel-backport-tracker	14	Track upstream stable backports, detect cherry-picks, check KABI impact, compare symvers
Patch Tracker	kernel-patch-tracker	11	Track full patch pipeline: mailing list → review → maintainer pickup → git trees
CVE Tracker	kernel-cve-tracker	8	CVE triage via vulns.git (primary) + NVD. Exact fixing commits, affected versions, fix verification
Lore Search	kernel-lore-search	6	Search and browse kernel mailing list archives on lore.kernel.org
Regression Helper	kernel-regression-helper	7	Track regressions via Fixes: tags, analyze bisect windows, generate bisect scripts
Config Analyzer	kernel-config-analyzer	7	Parse .config files, diff configs, explore Kconfig dependency trees
Release Tracker	kernel-release-tracker	7	Track stable releases, RC cycles, LTS status, compare versions
Dep Resolver	kernel-dep-resolver	12	Resolve prerequisite commits for backports (symbol gap + refactor + lore series cohort), steal from other stable trees, generate CVE backport plans

Installation

Requires Python 3.12+ and a Linux kernel git repository.

# Clone
git clone https://github.com/example/linux-kernel-mcp.git
cd linux-kernel-mcp

# Install with uv (recommended)
uv venv --python python3.12
uv pip install -e .

# Or with pip
python3.12 -m venv .venv
source .venv/bin/activate
pip install -e .

Quick Start

1. Prerequisites — what to clone

You don't need to clone everything. Two servers work with zero repos (Lore Search, Patch Tracker). The rest use local git repos that most kernel developers already have. Clone only what you need:

Repo	Clone command	Size	Who needs it
Your kernel tree	(you already have this)	—	Anyone doing kernel work
linux-stable	git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git	~4 GB	Backport tracking, release tracking, regression analysis
vulns.git	git clone git://git.kernel.org/pub/scm/linux/security/vulns.git	~50 MB	CVE triage (highly recommended — small and fast)
mainline	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git	~4 GB	Tracking if patches reached an official release
linux-next	git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git	~4 GB	Only if you send patches upstream and want to verify subsystem pickup

Typical setups:

• Distro kernel engineer (backports + CVE triage): linux-stable + your distro tree + vulns.git
• Upstream contributor (patch tracking): mainline + linux-next (or just mainline)
• Security/CVE triage: vulns.git + your target tree
• Just exploring: no repos needed — Lore Search and Patch Tracker work out of the box

Save disk space by sharing git objects between clones:

# Clone mainline first, then use --reference for others
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ~/linux
git clone --reference ~/linux git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux-stable

2. How it works

The servers run git commands against local repos on your disk. You tell them where your repos are via environment variables, set once in your AI client's config file. The servers don't clone repos, access remotes, or assume you're running from any particular directory.

Most tools also accept an explicit repo_path parameter, so the AI can query any tree — not just the pre-configured ones.

3. Test locally before configuring your AI client

Important: Run all commands from the project root directory (cd linux-kernel-mcp).

cd /path/to/linux-kernel-mcp

# Test a server that needs no repo (lore, patchwork, CVE search)
npx @modelcontextprotocol/inspector .venv/bin/kernel-lore-search

# Test a git-based server — pass repo paths as env vars
KERNEL_UPSTREAM_REPO=~/linux-stable \
KERNEL_TARGET_REPO=~/my-kernel-tree \
npx @modelcontextprotocol/inspector .venv/bin/kernel-backport-tracker

This opens the MCP Inspector in your browser where you can list tools and call them interactively.

Note on mcp dev: Do not use mcp dev linux_kernel_mcp/servers/lore_search.py — it loads the file directly which breaks the relative imports (from ..shared import ...). Use npx @modelcontextprotocol/inspector with the installed entry point instead, or use the dev helper:

# Using the dev helper (supports all 8 servers)
.venv/bin/mcp dev dev.py                     # defaults to lore_search
.venv/bin/mcp dev dev.py:backport_tracker    # specific server
.venv/bin/mcp dev dev.py:cve_tracker

Configuration

Environment Variables

Set these in your AI client's config (see examples below). They tell the git-based servers where your kernel repos are.

Variable	Used By	Description
KERNEL_UPSTREAM_REPO	Most servers	Path to upstream kernel git repo (e.g. linux-stable)
KERNEL_TARGET_REPO	Backport/CVE tracker	Path to your target kernel tree (e.g. your distro fork)
KERNEL_TARGET_BRANCH	Backport tracker	Branch to check in target repo (default: HEAD)
KERNEL_REPOS	Patch tracker	JSON dict of named repos for multi-tree tracking (see below)
KERNEL_VULNS_REPO	CVE tracker, Dep Resolver	Path to local clone of vulns.git (authoritative kernel CVE data)
KERNEL_STABLE_REPOS	Dep Resolver	JSON dict of other stable trees for steal searches (see below)

Understanding KERNEL_UPSTREAM_REPO vs KERNEL_REPOS

Most servers need just one kernel tree — KERNEL_UPSTREAM_REPO. This is a single path that you point at whichever repo is relevant for that server's job:

# For backport/release tracking → point at linux-stable
KERNEL_UPSTREAM_REPO=/home/user/linux-stable

# For config analysis → point at any kernel tree with Kconfig files
KERNEL_UPSTREAM_REPO=/home/user/linux

There is no separate KERNEL_MAINLINE_REPO or KERNEL_NEXT_REPO because most servers only query one tree at a time. Having 5+ variables that most servers ignore would add complexity for no benefit.

The exception is multi-tree patch tracking. When you want to check if a patch landed in mainline, linux-next, stable, and your distro tree all at once, use KERNEL_REPOS — a single JSON dict that gives each tree a name:

KERNEL_REPOS='{"mainline":"/home/user/linux","next":"/home/user/linux-next","stable":"/home/user/linux-stable","distro":"/home/user/uek"}'

Only the Patch Tracker uses KERNEL_REPOS. If it's not set, patch tracking falls back to checking KERNEL_UPSTREAM_REPO and KERNEL_TARGET_REPO.

Which servers need which variables?

Server	Repos needed	Variables	What to point KERNEL_UPSTREAM_REPO at
Backport Tracker	linux-stable + your tree	KERNEL_UPSTREAM_REPO, KERNEL_TARGET_REPO	linux-stable
CVE Tracker	vulns.git (+ your tree for fix check)	KERNEL_VULNS_REPO, KERNEL_TARGET_REPO	—
Regression Helper	Any kernel tree	KERNEL_UPSTREAM_REPO	linux-stable or mainline
Config Analyzer	Any kernel tree	KERNEL_UPSTREAM_REPO	Any tree with Kconfig files
Release Tracker	linux-stable or mainline	KERNEL_UPSTREAM_REPO	linux-stable (has all release tags)
Dep Resolver	linux-stable + your tree (+ vulns.git for CVE input)	KERNEL_UPSTREAM_REPO, KERNEL_TARGET_REPO, KERNEL_VULNS_REPO (optional, for CVE → commits), KERNEL_STABLE_REPOS (optional, for steal searches)	linux-stable or mainline
Patch Tracker	None required; repos optional	KERNEL_REPOS (optional)	—
Lore Search	None	—	—

Multi-tree patch tracking (KERNEL_REPOS)

Kernel patches travel through a pipeline: subsystem tree → linux-next → mainline → stable → distro. The Patch Tracker can check all of these at once if you configure KERNEL_REPOS as a JSON dict:

"KERNEL_REPOS": "{\"mainline\": \"/home/user/linux\", \"next\": \"/home/user/linux-next\", \"stable\": \"/home/user/linux-stable\", \"distro\": \"/home/user/uek\"}"

Then ask: "has my patch landed anywhere?" — the AI calls get_patch_lifecycle and reports the full status: mailing list → reviews → maintainer pickup → which trees have it. If KERNEL_REPOS is not set, it falls back to KERNEL_UPSTREAM_REPO and KERNEL_TARGET_REPO.

Steal searches across stable trees (KERNEL_STABLE_REPOS)

The Dep Resolver can search other stable branches for existing backports of a commit. If 6.6.y already backported a fix with adaptations, that version often applies more cleanly to your 5.15.y tree than the raw mainline patch.

Configure KERNEL_STABLE_REPOS as a JSON dict mapping names to "repo_path:branch":

KERNEL_STABLE_REPOS='{"6.6.y":"/home/user/linux-stable:linux-6.6.y","6.1.y":"/home/user/linux-stable:linux-6.1.y"}'

Multiple entries can point at the same repo with different branches. If the branch is omitted, HEAD is used. This variable is optional — you can also pass search_repo and search_branches directly to the steal_stable_backport tool.

Example: full setup for a distro kernel engineer

# Backport Tracker, Regression Helper, Release Tracker
KERNEL_UPSTREAM_REPO=/home/user/linux-stable

# Backport Tracker, CVE Tracker — your distro tree
KERNEL_TARGET_REPO=/home/user/uek

# CVE Tracker — authoritative kernel CVE data
KERNEL_VULNS_REPO=/home/user/vulns

# Patch Tracker — check all trees at once
KERNEL_REPOS='{"mainline":"/home/user/linux","next":"/home/user/linux-next","stable":"/home/user/linux-stable","distro":"/home/user/uek"}'

# Dep Resolver — steal backports from other stable branches
KERNEL_STABLE_REPOS='{"6.6.y":"/home/user/linux-stable:linux-6.6.y","6.1.y":"/home/user/linux-stable:linux-6.1.y"}'

# Dep Resolver — KERNEL_VULNS_REPO above is also picked up automatically
# for CVE → commits resolution in analyze_cve_backport

Important: Always use absolute paths in the config examples below. The AI client spawns the server as a subprocess and does not inherit your shell's working directory.

OpenAI Codex CLI

Add to ~/.codex/config.toml (global) or .codex/config.toml (project-scoped):

[mcp_servers.kernel-backport-tracker]
command = "/path/to/linux-kernel-mcp/.venv/bin/kernel-backport-tracker"
env = { "KERNEL_UPSTREAM_REPO" = "/path/to/linux-stable", "KERNEL_TARGET_REPO" = "/path/to/your-kernel-tree" }

[mcp_servers.kernel-lore-search]
command = "/path/to/linux-kernel-mcp/.venv/bin/kernel-lore-search"

[mcp_servers.kernel-cve-tracker]
command = "/path/to/linux-kernel-mcp/.venv/bin/kernel-cve-tracker"
env = { "KERNEL_TARGET_REPO" = "/path/to/your-kernel-tree" }

Or add via CLI:

codex mcp add kernel-lore-search -- /path/to/.venv/bin/kernel-lore-search
codex mcp list

Note: Codex uses TOML (not JSON) and the key must be mcp_servers (with underscore). Codex only supports local stdio servers — the same transport these servers use.

Tool Reference

Backport Tracker (14 tools)

• get_commit_info — Parse detailed commit metadata (tags, cherry-pick refs, Fixes:, Cc: stable)
• check_backport_status — Check if an upstream commit is backported (4 detection strategies)
• list_missing_backports — Find commits in an upstream range not yet backported (indexed batch check)
• check_patch_applies — Test if a patch applies cleanly to the target tree
• search_commits — Search commit history with filters
• find_fixes — Find commits that reference a given commit in Fixes: tags
• generate_fixes_tag — Generate a properly formatted Fixes: tag
• get_maintainer_info — Look up maintainers/reviewers/lists for a file (uses get_maintainer.pl or MAINTAINERS)
• compare_branches — Compare commits between two branches/tags
• get_stable_updates — Summarize changes between stable versions with subsystem breakdown
• find_kabi_changes — Find commits touching KABI-sensitive files (symvers, stablelist, kabi/)
• analyze_kabi_commit — Detect KABI preservation patterns in a commit (RH_KABI macros, GENKSYMS, reserved fields)
• check_kabi_impact — Analyze KABI impact of an upstream commit on the target tree
• compare_symvers — Compare Module.symvers CRC values between trees

Patch Tracker (11 tools)

• search_patches_lore — Search lore.kernel.org for patch submissions
• search_patches_patchwork — Search patchwork.kernel.org for patches by state/submitter
• get_patch_thread — Fetch a full patch thread with review tags
• get_review_summary — Summarize Reviewed-by/Acked-by/Tested-by/NAK tags
• check_patch_landed — Check if a patch landed in a specific git tree by subject match
• track_patch_across_trees — Check if a patch landed in mainline, linux-next, stable, distro, etc. (all configured trees at once)
• get_patch_lifecycle — Full pipeline tracking: checks mailing list → reviews → subsystem maintainer pickup (Patchwork) → all git trees in one call
• list_configured_trees — Show which kernel trees are configured for multi-tree tracking
• track_patch_series — Get full Patchwork series details
• list_patchwork_projects — List available Patchwork projects
• get_patch_events — Get Patchwork state change events

CVE Tracker (8 tools)

• get_cve_details — Full CVE details from vulns.git (primary) + NVD (CVSS scores). Exact fixing commits and affected version ranges.
• search_cves_vulns — Search CVEs in local vulns.git clone (fast, offline, authoritative)
• search_cves_nvd — Search NVD for kernel CVEs by severity/date (fallback, rate-limited)
• get_affected_versions — Precise affected kernel version ranges from vulns.git
• check_cve_status — Check if a CVE fix is applied in your tree (vulns.git → NVD → cherry-pick detection)
• cve_triage_report — Batch triage: which CVEs are fixed/unfixed in your tree
• map_cve_to_commits — Map a CVE to its upstream fixing commits
• search_cve_lore — Search linux-cve-announce mailing list

Lore Search (6 tools)

• search_lore — Full Xapian syntax search (s:subject, f:from, d:date, rt:body)
• get_thread — Fetch a complete discussion thread
• get_raw_message — Fetch raw email message
• get_patch_from_lore — Extract diff content from a patch email
• search_discussions — Search non-patch discussion threads
• get_author_activity — Get an author's recent mailing list activity

Regression Helper (7 tools)

• find_fixes_for_commit — Find all commits that fix a given commit (via Fixes: tags)
• analyze_regression_window — List commits between good/bad points with known-fix annotations
• generate_bisect_script — Generate a git bisect run script
• search_regression_reports — Search lore for regression reports on a topic
• trace_fix_chain — Follow Fixes: chains (A fixed by B, B fixed by C, ...)
• find_related_regressions — Find historical Fixes: commits touching a file path
• check_stable_candidates — Find commits marked Cc: stable for backport

Config Analyzer (7 tools)

• parse_config — Parse a .config file with summary stats
• diff_configs — Compare two .config files (added/removed/changed symbols)
• lookup_symbol — Look up a Kconfig symbol: type, deps, help text, source file
• get_dependency_chain — Full dependency chain for a symbol
• find_symbol_users — Find what depends on or selects a symbol
• check_config_value — Check a specific symbol's value in a .config
• search_symbols — Search Kconfig symbols by name or prompt text

Dep Resolver (12 tools)

• analyze_cve_backport — End-to-end CVE/commit backport analysis: combines symbol-gap, refactor, and lore-cohort layers into one ordered cherry-pick plan
• resolve_dependencies — Find prerequisite commits via file-level analysis (one-hop)
• resolve_full_dependencies — Recursive symbol-gap chain (Layer 1, cross-file API deps)
• find_refactor_prereqs — Detect same-file refactor prereqs that block clean apply (Layer 2)
• find_lore_series_cohort — Find sibling [PATCH N/M] commits from the original lore submission (Layer 3, advisory)
• find_fix_cohort — Find follow-up fixes via Fixes: tags + same-CVE entries in vulns.git
• resolve_cve_to_commits — Map a CVE ID to its upstream fixing-commit hashes (vulns.git)
• steal_stable_backport — Search other stable branches for adapted backports you can reuse
• check_apply_sequence — Test if a list of commits applies cleanly to the target tree
• generate_backport_plan — Full pipeline: resolve deps + steal search + apply check in one call
• batch_resolve_dependencies — Resolve deps for multiple commits, deduplicate shared prereqs
• list_stable_trees — List configured stable repos, branches, and recent tags

Release Tracker (7 tools)

• list_stable_releases — List stable release tags for a series
• get_release_info — Detailed info about a specific release
• compare_releases — Compare two releases with subsystem breakdown
• get_rc_status — Current release candidate cycle status
• search_stable_queue — Search the stable mailing list queue
• get_longterm_status — Status of all LTS kernel series
• track_stable_updates — Recent stable updates with commit counts

Architecture

linux_kernel_mcp/
├── servers/             # 8 MCP servers (one FastMCP app each)
│   ├── backport_tracker.py
│   ├── patch_tracker.py
│   ├── cve_tracker.py
│   ├── lore_search.py
│   ├── regression_helper.py
│   ├── config_analyzer.py
│   ├── release_tracker.py
│   └── dep_resolver.py
└── shared/              # Shared libraries used by servers
    ├── git_ops.py       # Git operations, backport index, patch apply
    ├── lore.py          # lore.kernel.org Atom feed client
    ├── patchwork.py     # Patchwork REST API client
    ├── cve.py           # NVD 2.0 API + kernel CNA client
    ├── kconfig.py       # Kconfig/dotconfig parser
    └── maintainers.py   # MAINTAINERS file parser

Each server is a standalone MCP process communicating over stdio. Servers share library code but run independently — you can deploy just the ones you need.

External APIs Used

API	Servers	Auth Required
Local git repos	Backport, Regression, Config, Release, Dep Resolver	No
lore.kernel.org Atom feeds	Lore Search, Patch Tracker, Regression, CVE, Release	No
patchwork.kernel.org REST API	Patch Tracker	No
NVD 2.0 JSON API	CVE Tracker	No (rate-limited)

License

MIT