Greg Kroah-Hartman, “Fellow at the Linux Foundation… responsible for the Linux kernel stable releases… maintainer of a variety of different kernel subsystems (USB, char/misc, tty/serial, driver core, staging, etc.)”, has a couple of interesting talks on the impact of LLMs on security: Linux in the Land of LLMs (August 11, 2026) and Kernel Recipes 2026 – Security in the LLM age (September 22, 2026). There are already nice discussions and summaries of these, like this one from sparsenotes.com or this Reddit thread on the first talk, but I wanted to capture the links that Greg KH shared plus a thought or two.
Slides are currently available online for the first talk: LLMs and the kernel security process [PDF].
I think the overall message is captured by the slide seen in these photos from the 2nd talk: “Do not panic” — a lot of the bug reports are not of real concern: some are pure fakery, some are known issues (and likely were “discovered” by reading the original reports), some are duplicative of others in the same batch, and many are not exploitable. Some are real though.
Similar waves of new exploits have been seen before, e.g., with the advent of fuzzing. We can use same tools being used by attackers to identify the issues, then work methodically to address them. He quotes from Andor: “I am condemned to use the tools of my enemy to defeat them.”
However, he starts with some concerning numbers, saying that the mean time to exploit has dropped from 63 days in 2018 to -7 days in 2026:
The source for these numbers may be a report from a Google: “M-Trends 2026 reveals that the mean time to exploit vulnerabilities dropped to an estimated -7 days, meaning exploitation is routinely occurring before a patch is even released.” And also: “At the same time, Google Threat Intelligence Group (GTIG) has observed that the mean time to exploit (TTE) for vulnerabilities has continually decreased from 63 days in 2018 to -1 day in 2024 and further downward to an estimated -7 days in 2025. A negative number indicates that exploitation of a vulnerability, on average, occurred before a patch was released.” (Not sure why Greg KH has 5 days for 2024 while Google says -1.)
An October 2024 article from Google has some more numbers: “Time-to-exploit (TTE) is our metric for defining the average time taken to exploit a vulnerability before or after a patch is released. Historically, our analyses have seen reduced times-to-exploit year over year. Through 2018 to 2019, we observed an average TTE of 63 days. From 2020 to the start of 2021, that number decreased to 44 days. Then, across all of 2021 and 2022, the average observed TTE dropped further to 32 days, already half of our first tracked TTE starting in 2018. In 2023, we observed the largest drop in TTE thus far, with an average of just five days.”
Putting the Google numbers into tabular form:
| Year | Time-to-exploit (days) |
| 2018 | 63 |
| 2020 | 44 |
| 2021 | 32 |
| 2023 | 5 |
| 2024 | -1 |
| 2025 | -7 |
(Are the complete numbers not published somewhere by Google in tabular form? Any mistakes in how I lined things up? It seems a little fuzzy which year some of the numbers belong to, perhaps accounting for the differences from Greg KH’s slide.)
Greg KH includes a quote from Thomas Dullien / Halvar Flake: “Software was never designed for perfect security, that choice is now catching up with us.” (Looks like Thomas Dullien / Halvar Flake has a lot of interesting writings: https://thomasdullien.github.io/. The quote seems to be translated from the title of a German article from him on Mythos, published in FAS in May 2026: “Software war nie auf perfekte Sicherheit ausgelegt – das rächt sich jetzt“, found via tzafaar.codeberg.page.)
Links:
- Discussion of false positives: https://lore.kernel.org/all/2026071406-ambiance-rogue-39bb@gregkh/ “Right now the LLMs seem to be running at about 1/3 to 1/4 of ‘false positives’, and these two patches are a good example of that.”
- “A Few Billion Lines of Code Later: Using Static Analysis to find Bugs in the Real World”: from the creators of Coverity, highlighting the importance of false positives — “False positives do matter. In our experience, more than 30% easily cause problems. People ignore the tool.”
- “Sashiko is an agentic Linux kernel code review system. It monitors public mailing lists to thoroughly evaluate proposed Linux kernel changes”: https://sashiko.dev/
- Source code: https://github.com/sashiko-dev/sashiko
- “Review Prompts for AI-Assisted Code Review”: https://github.com/masoncl/review-prompts
- Uses https://github.com/facebookexperimental/semcode: “Semcode is a semantic code search tool for C/C++ codebases that indexes your codebase and allows you to search for functions, types, and code patterns using both exact matches and semantic similarity.”
- “Find bugs in YOUR code using OpenCode, Llama.cpp and Qwen3.6”: https://wtarreau.blogspot.com/2026/05/find-bugs-in-your-code-using-opencode.html
- Mentions the following agents/harnesses:
- https://openssf.org/resources/securing-open-source-in-the-age-of-ai-a-practical-guide/
Leave a Reply