Linus Torvalds released Linux 7.4-rc2, the second release candidate for Linux 7.4, on November 9 (Japan time). In the announcement, he relayed the BPF maintainer's view that bug fixes are starting to outpace new discoveries. The report is encouraging at a time when AI-assisted bug hunting continues, but Torvalds himself did not declare that things have improved. BPF is a mechanism for running programs inside the Linux kernel, and it includes a verifier that checks programs before they run for hazards such as unsafe memory access. Still, fewer new bugs turning up is not the same as fixes catching up with new reports. Looking at the November 3 merge record and a specific verifier fix shows both what is actually improving and what challenges remain.
BPF fixes may be outpacing new reports, but the improvement is limited
In the description of the fixes merged on November 3, BPF maintainer Alexei Starovoitov said the pace of fixing bugs appeared to be exceeding the pace of new discoveries. Torvalds highlighted this assessment in the 7.4-rc2 announcement. However, the BPF merge record also notes that the situation is not yet out of the woods and that the sockmap fixes will come later. Torvalds welcomed the improvement, if real, but said many other areas have not yet reached the same state. In the 7.4-rc2 release announcement, he urged people to keep testing, and he did not claim that bug fixes have overtaken new discoveries across Linux as a whole.
Fixes can outpace new reports because fewer new bugs are being found, because fixing has become faster, or because both are happening at once. However, neither the announcement nor the merge record provides statistics such as the number of new reports, the number of fixes, or the number of unresolved issues over a given period. Time spent on review is also unknown, so it is impossible to tell whether the bugs that AI-driven searches can find are running out or whether maintainers' workloads have eased. What can be confirmed at this point is that the BPF maintainer has begun to view the progress of fixes positively.
Don't confuse the size of 7.4-rc2 with the number of AI-driven fixes
Part of the reason the 7.4-rc2 changes are large is that automated Coccinelle changes were carried over from the first release candidate (rc1). Coccinelle is a tool that detects specific patterns in source code and rewrites them in bulk. Torvalds explained that, to avoid handling these changes while traveling, he held them out of rc1 and moved them to rc2. Most of the changes are simple edits of a line or two, but they are spread across thousands of files, so they account for a large share of the overall change volume.
According to Torvalds, excluding the automated Coccinelle changes, about one-third of the changes relate to drivers, about one-third to networking and BPF, and the rest to file systems, memory management, changes for individual CPU architectures, and so on. This is a rough breakdown of change volume by development area, not a count of bugs found by AI. The release announcement also distinguishes between the mechanical Coccinelle rewrites and fixes related to AI-assisted bug discovery.
In the first place, the number of changed files or commits does not directly equal the number of bugs. Fixing one bug can require multiple commits, and tests to verify a fix may be added as separate commits. To understand what is actually progressing in BPF, it is necessary to look not only at the volume of changes but also at what the fixed code does and at the tests that confirm the fixes are correct.
What BPF's 61 commits show about fixing and verification
The 61 BPF commits merged on November 3 include not only code that fixes bugs but also tests that confirm the fixes work and prevent regressions. In other words, this does not mean 61 vulnerabilities were found. The "61 commits" notation in the merge record and the list of commit subjects confirm at least the following two kinds of work.
| Commit category | Main work | Caveat when reading the numbers |
|---|---|---|
Core bpf: fixes |
Correct faulty handling in the verifier and elsewhere | The commit count does not match the number of bugs or AI-generated fixes |
selftests/bpf: tests |
Verify the behavior being fixed and prevent the bug from recurring | Added tests are included in the 61 commits |
Because the list of commit subjects in the merge record is truncated at the end, the exact breakdown and proportions of all 61 commits cannot be calculated. Even so, it is clear that fixing bugs involves not only rewriting faulty handling but also verifying behavior after the fix. In BPF in particular, it is important both to avoid running dangerous programs and to avoid wrongly rejecting safe ones.
The BPF verifier is not merely a mechanism that scans program instructions for dangerous operations. It tracks the types and possible ranges of values held in registers, which areas of the stack have been written to, and more, preventing out-of-bounds memory access and reads of uninitialized data. This analysis, described in the official Linux kernel documentation, is the foundation for determining whether a program can be run safely.
One example of an inconsistency in this tracking was fix commit cdefba74 from November 2. The problem involved the fact that a called function can overwrite a pointer saved on the caller's stack. Even if, at run time, the pointer was changed to point to a different memory region, the analysis side did not correctly recognize the change and could keep processing on the assumption of the earlier target. The actual state of the program and the internal information used for verification had diverged.
According to the fix commit's description, this inconsistency could cause two kinds of problems. One is that the analysis could miss a write that actually occurs and allow access outside a BPF map's region. The other is that a program that could safely run might be wrongly rejected. In the latter case, the analysis could judge a stack value that was still needed to be unnecessary and then treat a subsequent read as invalid. The same pointer-tracking inconsistency led to misjudgments in opposite directions: accepting dangerous programs and rejecting normal ones.
The fix makes the analysis stop treating the target of a pointer on the caller's stack as settled when the called function can overwrite that pointer. It is a mechanism that accounts for the possibility of overwriting and avoids making decisions based on information that is not certain. This can improve safety, but because it changes analysis precision, its effect on programs that were previously accepted also has to be checked. Even if the fix code is relatively small, its impact is not necessarily small.
The fix's author reported examining the impact using the Linux kernel selftests plus a total of 12,522 programs, including Cilium and sched_ext. As a result, stack-tracking information changed in only 4 programs, and there was no change in the accept/reject outcomes, the number of instructions analyzed, or the number of states during analysis. This means that, within the reported test scope, the impact on existing programs was limited. However, it does not guarantee compatibility or performance in every environment, including unknown programs. What matters is that, after adding a fix that improves safety, the author checked with concrete numbers whether existing programs' outcomes were adversely affected.
Note that there is no explicit statement that AI discovered this pointer-tracking problem or generated the fix code. It is a concrete example of a BPF fix made while AI-assisted bug hunting is intensifying, but it cannot be counted as evidence of AI's discovery capability.
Turning AI-found bugs into verified fixes
The Linux kernel has also established procedures for using AI to find and fix bugs. The official document "AI Coding Assistants" asks that issues flagged by AI not be reported as they are, but that people confirm whether they are bugs that actually occur. It makes drafting a fix mandatory except in minor cases, and also asks that the fix be confirmed to work through builds, reproduction code, and re-analysis. The procedure emphasizes the work of submitting an applicable fix, not just having AI find suspicious code.
Specifically, one first identifies the version or commit where the problem exists and reproduces the bug as far as possible. Then one writes the fix and verifies it again under the conditions that triggered the original problem. The fix must not generate new build warnings and must pass the checkpatch.pl check, which examines code style and more. It is also required to attach a Fixes tag indicating the commit that introduced the problem and to identify the maintainers and mailing lists to which the fix should be sent.
The key point is that one must not report verification as done when it has not been. If reproduction code could not be created, or if builds or tests could not be run, that fact must be stated explicitly. If confirmed facts are clearly separated from impacts the AI merely inferred, maintainers can see what verification remains. Conversely, with a report where it is unclear how much has been confirmed, maintainers have to start over by investigating whether the problem exists at all.
The "Security bugs" guide, which deals with security issues, describes in more concrete terms the burden that AI-assisted bug reports impose. AI-generated reports tend to contain unnecessarily long text and excessive decoration, making important information hard to find. Reports that exaggerate impacts based on speculation without actual confirmation also make assessing the problem harder. If reports of irreproducible bugs increase, maintainers end up spending time investigating problems whose existence has not been confirmed. For this reason, the guide asks that reports clearly state the affected versions or commits, a concrete description of the problem, reproduction code, and the conditions under which it occurs.
The same guide also mentions cases in which multiple researchers using AI discover the same bug almost simultaneously. For this reason, it instructs that problems found using AI be treated in principle as public information, while reproduction code should not be published to prevent abuse and should be shared privately when maintainers request it. However, it also allows private reporting when it is hard to judge whether something qualifies as a security vulnerability. The policy is not to publish everything found with AI unconditionally; responses are expected to fit the content of the report and the risk.
Responsibility for submitted code ultimately rests with humans as well. "AI Coding Assistants" prohibits AI agents themselves from adding the Signed-off-by tag, which certifies a developer's responsibility for the code's origin and licensing. A human developer must review AI-generated code, confirm that licensing requirements are met, and take responsibility for the contribution as a whole. Even if AI can find a bug and generate a fix, that alone does not mean it can be merged into the Linux kernel.
There is no measurement showing that the improved fix pace in BPF resulted from these development procedures. Even so, as AI-driven bug hunting spreads, it is increasingly important to carry out the whole process, from confirming reproducibility through fixing and testing, and not merely to count discoveries. Torvalds's call for continued testing in the 7.4-rc2 announcement reflects the fact that reports of progress on fixes are not enough on their own. Going forward, whether the state in which BPF fixes outpace new reports continues, and whether unresolved problems actually decrease, will be key indicators for judging the improvement.