On Tue, Jul 14, 2026 at 12:46:41PM +0200, Spuntik wrote: > >From 9b140a7e28c8480ab51bc5441c4d40fa5e5a4e90 Mon Sep 17 00:00:00 2001 > From: spuntik1205 <[email protected]> > Date: Tue, 14 Jul 2026 12:22:32 +0200 > Subject: [PATCH] Add SECURITY.md to redirect GitHub users to official > security channels > > GitHub natively supports a `SECURITY.md` file in the root of the > repository. When this file is present, GitHub automatically > creates a "Security" tab for the repo and displays a prominent link to > this policy whenever a user attempts to open a new issue. > > Since the Linux kernel mirror on GitHub receives a lot of traffic from > users who may not be familiar with the kernel's > mailing-list workflow, they might incorrectly attempt to report > security vulnerabilities through public GitHub channels. > > This PR adds a standard `SECURITY.md` file that: > 1. Explicitly asks users not to report vulnerabilities on GitHub.
Do people actually do this? If so, that should be disabled as no one looks at it. > 2. Directs them to the official `[email protected]` mailing list. No, you need to read the security documentation which tells you how to do this. > 3. Links directly to the official `security-bugs.rst` documentation on > kernel.org for proper reporting procedures. That's better, but really, step 2 is not correct. > While I understand the kernel does not use GitHub for development, > adding this file will help intercept confused GitHub users > and redirect them to the proper kernel security workflows. > --- No signed-off-by or real authorship information? And no, we don't add files for github only, sorry. > SECURITY.md | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > create mode 100644 SECURITY.md > > diff --git a/SECURITY.md b/SECURITY.md > new file mode 100644 > index 000000000000..80b0b46279f6 > --- /dev/null > +++ b/SECURITY.md > @@ -0,0 +1,19 @@ > +# Security Policy > + > +## Supported Versions > + > +The Linux kernel maintains several active branches. The mainline > kernel, stable kernels, and longterm maintenance (LTS) kernels are > currently supported with security updates. > + > +Please refer to the [active kernel > releases](https://www.kernel.org/category/releases.html) on kernel.org > to see which versions are currently receiving security updates. > + > +## Reporting a Vulnerability > + > +**Please do not report security vulnerabilities through public GitHub > issues.** > + > +If you believe you have found a security vulnerability in the Linux > kernel, please report it to the Linux kernel security team. > + > +1. **Email the Security Team:** Send an email to `[email protected]`. > +2. **Read the Documentation:** For detailed instructions on what to > include in your report, acceptable disclosure timelines, and how the > kernel team handles security bugs, please read the official [Security > Bugs > Documentation](https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html). > +3. **Hardware Vulnerabilities:** If you are reporting a hardware > vulnerability that affects the kernel, please refer to the specific > guidelines for [Hardware > vulnerabilities](https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html) > and contact the hardware security team at > `[email protected]` if appropriate. > + > +The security team will review your report and work with you and the > relevant subsystem maintainers to develop and release a fix. You can > typically expect an initial response within a few days. Really? We don't provide any QoS guarantees :) thanks, greg k-h
