AWS Shows Use of AI Agents to Triage Linux Kernel CVEs

Engineers from Amazon Web Services (AWS) have described how the team that maintains the Linux kernel for EC2 infrastructure handles kernel CVEs. The process combines an automated filter, an AI agent and human review. The team also argues that it needs to move to newer long-term-support (LTS) kernels, as older branches collect fixes that are never backported.

Dylan Johnson and Justinien Bouron gave the talk at the Linux Plumbers Conference in Prague earlier this month. At the start of the recording, Johnson explains that the team maintains the kernel used within EC2 infrastructure. This is separate from Amazon Linux and from the kernels that customers run in their virtual machines.

After the kernel project became a CVE Numbering Authority in February 2024, the team saw about two kernel CVEs a week before 2024 and about 16 a day afterwards, with 848 published on 15 August 2026. The kernel CVE documentation states that the project cannot know how a given system uses the kernel, so users must decide which CVEs apply to them.

The first stage of AWS's process does not use AI. Bouron explained that kernel CVE records are published in JSON and list the affected versions and source files. A script discards a CVE if the kernel version is outside the affected range, or if none of the listed files are built into the image. In AWS's environment this removes about 70% of CVEs, although Bouron said the figure depends heavily on kernel configuration.

The remaining CVEs go to an AI agent. It receives AWS's kernel source tree, the configuration for each platform, a description of the environment and threat model, and a severity rubric. The agent produces a table that records the affected subsystem, the vulnerability type and the attack vector. Bouron said the team ignores CVSS scores, because they are not specific to its environment.

"We're really using it as a very fancy classifier."
Dylan Johnson

Two engineers usually review the table. According to the slides, the agent needs about 3.4 seconds per CVE, compared with minutes for a person. Bouron said review is now the slowest step in the process, and that the team does not intend to remove it.

"We don't want to hinge our entire security posture on the output of an LLM agent."
Justinien Bouron

When asked about accuracy, Bouron estimated that between 5% and 10% of the agent's decisions were problematic. This was an informal estimate, and the talk did not describe a formal evaluation.

The team also disabled kernel features it did not need, to reduce the number of applicable CVEs. Bouron called this approach "deceptively difficult". The slides list more than 32,000 configuration options, and removing the wrong one can cause bugs or performance regressions that appear months later.

The team's data also shows that older LTS branches receive fixes later and carry more unfixed CVEs. For CVEs affecting all six branches studied, the median time from a mainline fix to an LTS release was 31.8 days for Linux 5.10 and 18.1 days for 6.18. On 16 September, 1,709 known CVEs were unfixed in 5.10, compared with 229 in 6.18. These are counts for each branch, and they do not show how many affect AWS's own kernel.

Backporting fixes in-house brings its own risks. Bouron pointed out that CVE records often name only the final fixing commit. A team that misses the prerequisite commits may still be vulnerable after applying the listed fix.

AWS has shortened its own upgrades. Johnson said the move from 4.19 to 5.10 took about two years, measured from the start of porting work to full production deployment. The next upgrade took about a year, and the move to 6.18 took about six months. During the 5.10-to-6.12 upgrade, 43% of tracked issues were fixed in userspace, where workloads depended on older kernel behaviour. Johnson said the team will now run stable kernels in testing through the year, and move the fleet when each new LTS release appears.

Microsoft's Azure Linux team described a similar pipeline at the same conference. Its triage verdicts come from a rule table, and AI only suggests inputs to it. The team uses agents for backporting, and reported that a build-and-test feedback loop raised its success rate from about 50% to 80%. Google DeepMind's CodeMender, which InfoQ covered in October 2025, focuses on writing fixes. Its announcement stated that human researchers review every patch before it is submitted upstream.

Berend de Boer, CTO of Process Focus, commented on LinkedIn about the work involved in running cloud infrastructure. He listed host patching and Linux CVEs among the work that organisations take on when they build their own cloud. "Focus on what makes your business valuable to your customers," he wrote.

AWS has not released the tools. Asked about open-sourcing them, Johnson said the team would like to explore sharing the filtering tool. He also acknowledged that AWS's internal users make it easier to disable features than it would be for a general-purpose distribution.