At a Linux Plumbers Conference talk earlier in October 2026, Amazon Web Services (AWS) engineers described a two-stage system for triaging security flaws in the Linux kernel maintained for EC2 infrastructure. A script first filters Common Vulnerabilities and Exposures (CVEs), which are records of known security flaws; an AI agent classifies the remaining cases, and engineers review its results before deciding what to do. The workflow covers AWS’s infrastructure kernel, not Amazon Linux or kernels running inside customers’ virtual machines.
How the filter and AI hand off CVEs
The first stage uses no AI. A script compares each CVE’s affected version range and listed source files with the kernel version and files built into the relevant AWS image. AWS said this filter removed about 70% of CVEs in its environment. The share depends heavily on the environment and kernel configuration, so it is not a general rate for other systems.
The AI agent then processes the remaining CVEs. AWS’s presentation says it receives a custom kernel tree, kernel configuration, a threat model and a severity rubric. It returns a table with one row per CVE, including fields such as subsystem, vulnerability type and attack vector.
The agent classifies; engineers review
AWS’s workflow keeps people in the decision loop. Two engineers usually review the agent’s table, and that review is the slowest stage of the process. The agent classifies vulnerabilities for review; the described system does not itself patch or remediate them.
AWS reported that the agent processes a CVE in about 3.4 seconds, compared with minutes for human triage. That figure covers classification time per CVE, not review, fixes, testing or deployment. Justinien Bouron informally estimated that 5% to 10% of the agent’s decisions were problematic. The presentation did not provide a formal evaluation of that estimate.
Kernel upgrades take work beyond the kernel
AWS’s figures for the upgrade from Linux 5.10 to 6.12 show that tracked issues extended across the software stack and platform. The shares below are portions of tracked upgrade issues, not CVEs or remediation time.
| Area where tracked issues were addressed | Share of issues |
| Kernel space | 45% |
| Userspace | 43% |
| Kernel configuration | 7% |
| Firmware or hardware | 5% |
AWS also said that 15% of the kernel-space fixes were upstreamed, meaning contributed to the mainline Linux project. The breakdown helps explain why qualifying a kernel upgrade can involve more than changing kernel code: AWS reported issues in userspace, configuration, firmware and hardware too.
AWS described specific compatibility work during upgrades. A change in virtual memory area storage slowed mmap() and munmap() operations, prompting AWS to reduce mapping operations. A scheduler change altered fork() timing, leading to changes in how AWS used fork patterns. A higher default maximum request size in the block layer caused firmware I/O timeouts that AWS addressed with sysctl tuning.
AWS reported that its upgrade from 4.19 to 5.10 took 24 months, the move from 5.10 to 6.12 took 12 months, and the move from 6.12 to 6.18 took six months. It attributed the shorter timelines to better tooling, broader test coverage and an experienced team. Its presentation also described more than 32,000 kernel configuration options and warned that disabling the wrong one can cause subtle bugs or performance regressions.
What the LTS branch figures measure
Long-term support (LTS) branches receive ongoing maintenance. AWS’s snapshot dated September 16, 2026, counted unfixed CVEs across Linux branches and measured the median time from a fix being merged into mainline to its release in an LTS branch.
| Linux LTS branch | Unfixed CVEs on September 16, 2026 | Median mainline-fix-to-LTS release time |
| 5.10 | 1,709 | 31.8 days |
| 5.15 | 1,567 | 31.5 days |
| 6.1 | 1,062 | 28.8 days |
| 6.6 | 762 | 23.1 days |
| 6.12 | 483 | 19.0 days |
| 6.18 | 229 | 18.1 days |
The CVE counts apply to the LTS branches, not specifically to AWS’s deployed EC2 kernel. The release intervals measure the path from a mainline fix to an LTS release, not how long AWS takes to deploy a fix.
AWS’s response depends on the case
AWS described four possible responses after assessing whether a CVE applies to its environment: take no action when it does not apply; wait for the next LTS patch when the impact can wait; cherry-pick a fix when faster remediation is needed; or use a workaround when a kernel update is not possible. The appropriate choice depends on the vulnerability and the system’s circumstances. AWS also warned that backporting fixes to older, more divergent branches can be difficult, and that a CVE record may omit prerequisite commits.
Dylan Johnson said AWS wanted to explore sharing its filtering tool.
