Linux Kernel 7.3 AI Patch Tagging Progress

On September 6, 2026, Linus Torvalds signed off Linux 7.3-rc2 and told everyone to blame AI for how heavy it was, with a wink. The Next Web noted that a month earlier he had raised the same subject without the joke. The same cycle carried a quieter change with far more staying power: the kernel project now asks contributors to tag patches that AI helped write.

A tag is auditable in a way that a mailing-list debate is not. Kernel patches go to maintainers who reject work for style as readily as for correctness, and an untagged assisted patch looks identical to a hand-written one until it lands in a tree and misbehaves. Tagging puts the assistance in git log, where anyone with a checkout can count it. It does not measure usage: a contributor who skips the tag leaves nothing behind.

The measured results from 2026 are less ambiguous than the policy. AUTODRIVER’s LLM pipeline compiled 56.4% of the driver patches it generated across 55 evaluated cases. Retrieval-augmented triage hit 91% recall on a hand-labeled false-positive set. A libclang pass catalogued 1,289 ioctl command codes that had no central inventory before it ran. Three results, three different verdicts on how much to trust a model with code that executes in ring 0.

Linux 7.3 Ships, 7.4 Opens With a Scheduling Warning

Torvalds released 7.3 on a Sunday afternoon, per the LWN release notice, managing to keep track of the day of the week well enough to avoid an off-schedule tag. Volume arrived early: LWN counted 2,346 non-merge changesets already in mainline at the start of the merge window, and called that figure a down payment on what was still coming.

LLM Driver Patching: 56.4% Compilation Success

AI Disclosure Moves Into Commit Trailers

Outside the tree, Phoronix reported that Torvalds has been working on a kernel improvement with Claude Code, which makes the disclosure policy easier to read as practice than as principle. A trailer is only as useful as the audit you run on it. This script tallies trailer keys across the commit history of one subsystem, so you can see what a tree actually records instead of what the process document says it should.

#!/usr/bin/env python3
"""Tally commit trailers for one subsystem path.

Usage: python3 trailer_tally.py ~/linux drivers/gpu 500
Note: production use should stream git output rather than buffering
the whole log, and handle non-UTF-8 author names.
"""
import collections, subprocess, sys

repo, path, limit = sys.argv[1], sys.argv[2], sys.argv[3]
log = subprocess.run(
 ["git", "-C", repo, "log", "-n", limit,
 "--format=%x00%(trailers)", "HEAD", "--", path],
 capture_output=True, text=True, check=True,
).stdout

counts = collections.Counter()
for record in log.split("\x00"):
 for line in record.splitlines():
 key, sep, _value = line.partition(": ")
 if sep:
 counts[key.strip()] += 1

for key, n in counts.most_common():
 print(f"{n:5d} {key}")

# sample run against a local checkout (your tree and range will differ):
# 418 Signed-off-by
# 187 Reviewed-by
# 29 Co-developed-by

Two limits deserve stating plainly. Trailers measure disclosure, not usage; a contributor who omits the tag produces a tree that looks clean. And a tally says nothing about whether an assisted patch was correct, only that someone recorded the help. That gap is why the benchmarks below carry more weight than any process document.

LLM Driver Patching: 56.4% Compilation Success

Kernel API and ABI changes break out-of-tree drivers continuously, and the cost lands on maintainers who never signed up to chase mainline. AUTODRIVER, described in a November 2025 preprint, attacks that loop directly. The authors built DRIVEBENCH, an executable corpus of kernel-to-driver co-evolution cases spanning v5.10 to v6.10, validating 235 cases from 612 candidates, then wrapped a closed loop around it combining prompt engineering, multi-agent collaboration, static analysis, and iterative validation.

Across 55 evaluated cases, AUTODRIVER reached 56.4% compilation success. QEMU-based boot verification showed compiled patches preserving driver initialization in most instances. Read those numbers together: roughly four in ten generated patches do not build, and among those that do, an unstated share fails at device init. A pipeline that gets half the cases to a compiling, booting state lowers rebase cost; it does not remove the maintainer from the loop.

The reusable part is the harness, not the model. Any patch-generation loop needs a build gate and a boot gate before a human reads the diff.

#!/usr/bin/env bash
# Gate a generated driver patch: compile the widest config, then boot it.
# Usage: ./gate.sh ~/linux
set -euo pipefail
cd "${1:-$HOME/linux}"

make allmodconfig
make -j"$(nproc)" 2>&1 | tee build-allmodconfig.log

if grep -qE '^make(\[[0-9]+\])?: \*\*\*' build-allmodconfig.log; then
 echo "compile gate failed, see build-allmodconfig.log" >&2
 exit 1
fi

qemu-system-x86_64 -kernel arch/x86/boot/bzImage \
 -append "console=ttyS0 root=/dev/ram0" -nographic -no-reboot
# allmodconfig maximizes what the compiler checks, not what your target
# boots, so the QEMU pass is the one that catches init failures.

Three routes exist for a driver that mainline left behind. A manual rebase is predictable and expensive. Generated patches with gates, the approach the paper measures, trade maintainer hours for rejection rate. Upstreaming the driver ends the cycle, at the cost of review work you can never fully schedule. Pick based on how many kernel releases you plan to skip.

The ioctl Census: 1,289 Command Codes Across 878 Modules

ioctl is the kernel’s catch-all device-control interface: userspace hands a driver a numeric command code and an argument buffer, and the driver decides what both mean. The Linux IOCTL Census made that surface countable. An allmodconfig build compiled 878 modules across 169 subtrees, and a single deterministic libclang pass over the source recovered 586 ioctl dispatch entry points, 1,289 decoded _IOC command codes, 3,583 controlled-input sinks, and 1,298 permission gates.

The authors encoded the kernel’s documented threat model as a queryable column, separating the capability-ungated surface from the part a hard capability gate puts out of scope. They describe the ungated portion as an upper bound on unprivileged reach rather than proven reach, which is the honest framing: a missing gate is a precondition for an attack, not an exploit. The census was backtested against 22 recent in-tree ioctl CVEs, and the structural tier ships as open data on a schema shared with a companion Windows census.

Handler bugs follow a familiar shape. A driver trusts a length field it never validated, then reads or writes out of bounds in kernel context. Decoding the command code is the first step when auditing a handler, because the direction and size bits state what the driver promised to do with the buffer.

Note: The following code is an illustrative example and has not been verified against official documentation. Please refer to the official docs for production-ready code.

/* iocdec.c - decode a Linux ioctl command code.
 * Build: gcc -O2 -o iocdec iocdec.c
 * Note: covers the asm-generic encoding only; some architectures pack
 * direction and size fields differently, so check your arch headers.
 */
#include <stdio.h>
#include <stdlib.h>
#include <sys/ioctl.h>

int main(int argc, char **argv) {
 if (argc != 2) {
 fprintf(stderr, "usage: %s 0x40046b01\n", argv[0]);
 return 1;
 }
 unsigned long cmd = strtoul(argv[1], NULL, 0);
 printf("dir=%lu type=%c nr=%lu size=%lu\n",
 (unsigned long)_IOC_DIR(cmd), (char)_IOC_TYPE(cmd),
 (unsigned long)_IOC_NR(cmd), (unsigned long)_IOC_SIZE(cmd));
 return 0;
}
/* $ ./iocdec 0x40046b01
 * dir=1 type=k nr=1 size=4

Run it against the codes your own driver defines; a size field that disagrees with the struct you actually copy from userspace is the bug you are looking for. The census makes the same check possible at tree scale, mapping 586 entry points onto 1,298 gates so you can query which handlers a capability check covers and which are reachable only through unprivileged paths. That inventory did not exist before this year, and it is now the fastest way to scope an ioctl review before you open a single handler.

Bug Triage: 497 False Positives in a 2,006-Report Sample

False-positive reports consume maintainer effort without improving code. A 2026 empirical study hand-labeled 2,006 kernel bug reports from Bugzilla and Syzkaller: 1,509 genuine bugs, 497 false positives. The false ones clustered in file systems and drivers, mostly from external dependencies and semantic misunderstandings, and they demanded effort comparable to real bugs, with extended threads and slow closure.

For mitigation, retrieval-augmented generation did best among the prompting strategies the authors tested, reaching 91% recall and an F1 score of 88% on that dataset. Those figures come from a curated set and say nothing about performance on a live tracker; a triage model tuned for recall will still route some genuine bugs into the closed pile, which is why the authors frame the result as mitigation rather than automation.

An analysis of the regzbot dataset covering 2021 through 2024 found regression fixes averaging under a month, faster than earlier reports, with device drivers the most regression-prone subsystem. Review and manual testing did not explain the variation in fix times, and code churn carried only a weak statistical signal.

Effort	Target	Scale tested	Reported result	Source
AUTODRIVER / DRIVEBENCH	Kernel-to-driver co-evolution	235 validated cases from 612 candidates, v5.10 to v6.10; 55 cases evaluated	56.4% compilation success; boot check preserved driver init in most instances	arXiv 2511.18924
RAG false-positive triage	Bugzilla and Syzkaller reports	2,006 reports: 1,509 genuine, 497 false positives	91% recall, F1 score of 88%	arXiv 2605.07678
Linux IOCTL Census	ioctl control-code surface	Allmodconfig build, 878 modules, 169 subtrees	586 dispatch entry points, 1,289 command codes, 3,583 sinks, 1,298 permission gates; backtested on 22 in-tree ioctl CVEs	arXiv 2606.10290
regzbot regression analysis	Regression fix times	regzbot dataset, 2021 to 2024	Average fix time under a month; device drivers most regression-prone	arXiv 2411.02091

The three AI results point in different directions on purpose. Driver patching clears the compile gate slightly more than half the time, triage clears a curated recall bar, and static analysis sidesteps the question by counting instead of generating. None of them replaces a maintainer’s judgment, and the disclosure trailer now makes it possible to see how often that judgment is being applied to assisted work.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: