Linux kernel security work

Summary

Lots of the CVE world seems to focus on “security bugs” but I’ve found that it is not all that well known exactly how the Linux kernel security process works. I gave a talk about this back in 2023 and at other conferences since then, attempting to explain how it works, but I also thought it would be good to explain this all in writing as it is required to know this when trying to understand how the Linux kernel CNA issues CVEs. This is a post in the series about the Linux kernel CVE release process: Linux kernel versions, how the Linux kernel releases are numbered. Tracking kernel commits across branches, how to keep track of Linux kernel commits as they move from the main release branch into the different stable releases in an automated way. Linux kernel security work (this post), how the Linux kernel security team works to fix reported security bugs. tl;dr Summary up front for those not wanting to read a wall of text: The Linux kernel security team work to fix reported issues as quickly as possible and get the fixes merged to public trees, and do not do any announcements anywhere. The Linux kernel security team and the CVE team are different groups of people, all of whom do this work on their own recognition, not associated with any company. Only send plain text emails to the kernel security team. Do not email the kernel security team and expect to get a CVE assigned. Reactive, not proactive, security work The Linux kernel security team is group of Linux kernel developers who are responsible for triaging potential security bugs that are reported to them, and get them fixed as soon as possible. They do this work as “reactive” for security issues, independent of the great “proactive” kernel security work that the Kernel Self-protection project has been doing for the past 10+ years. Kernel security team As can be seen in the in-kernel documentation to contact the security team, just email the address in that document the potential issue that you have found, without u...