Properly Handling Linux Kernel Security Bugs: Complete Guide

This guide explains how to report, triage, and manage security bugs in the Linux kernel, including handling AI-assisted vulnerability reports. The new document clarifies which bugs should be considered security vulnerabilities and which can be managed through the normal public development process.

This guide is useful for developers, kernel maintainers, and security researchers working with the Linux kernel. It provides clear guidelines to improve the quality of security reports and ensure that critical vulnerabilities are handled effectively.

• Developers: To correctly report security bugs and contribute to improving the kernel.
• Kernel Maintainers: To efficiently manage and triage security reports.
• Security Researchers: To identify and report vulnerabilities in a structured and useful way for the community.

Prerequisites

• Access to the Linux kernel repository on git.kernel.org
• Knowledge of Linux kernel development and maintenance processes
• Familiarity with computer security concepts and software vulnerabilities
• Ability to read and understand technical documentation in English
• Access to tools for testing and verifying vulnerabilities and exploits

PROCEDURE: How to Correctly Report Security Bugs in the Linux Kernel

By the end of this guide, you will be able to correctly report security bugs in the Linux kernel, following the new guidelines introduced by Linus Torvalds.

• Step 1: Verify if the bug you found qualifies as a security vulnerability. According to the new documentation, only bugs that violate specific guarantees such as user isolation, process memory separation, restrictions on ptrace, IPC and network isolation, and protections enforced by Linux capabilities like CAPSYSADMIN, CAPNETADMIN, and CAPSYSPTRACE are considered security vulnerabilities.
• Step 2: Determine whether the bug should be reported publicly or privately. Most security bugs should be handled publicly, but the private security list is reserved for urgent, easily exploitable vulnerabilities that impact many users.
• Step 3: If the bug was found with the help of an AI assistant, discuss the discovery publicly, but do not publicly share the exploit code. Provide the exploit code privately only if requested by a maintainer.
• Step 4: Write a concise report in plain text, without Markdown. Start with key facts and describe the verified impacts of the bug, such as the ability of an unprivileged user to gain elevated privileges.
• Step 5: Verify and test the AI-generated exploit before sending it. Ensure the issue is reproducible and provide details on how to reproduce it.
• Step 6: Use AI not only to identify vulnerabilities but also to develop and test fixes.
• Step 7: Ensure the bug does not fall into the exceptions listed in the new documentation, such as issues from obsolete kernel branches, insecure build options, sysctl permissions, or filesystems, development-only features, or code in staging or experimental areas.
• Step 8: Send the report to the appropriate mailing list, following the Linux kernel bug reporting guidelines.

Verification and Troubleshooting

Functional Testing

• Verify bug reporting: Ensure security bugs are reported publicly, except for urgent and easily exploitable ones. Use the private security list only for exceptional cases.
• Check report quality: Verify that reports are concise, in plain text, and contain verified facts. Reports should describe concrete impacts, not hypothetical ones.
• Test AI-generated exploits: Before submitting a report, ensure the exploit is tested and reproducible. Share the exploit only privately upon request by maintainers.

Problem Solving

• Low-quality reports: If you receive low-quality reports, ask the reporter to rephrase them following the guidelines specified in the new documentation.
• Non-qualifying bugs: Identify bugs that do not qualify as security vulnerabilities, such as those from obsolete branches or non-standard configurations. These should be managed in the public development process.
• Problems with AI-assisted reports: If an AI-assisted report does not meet quality requirements, ask the reporter to provide additional verified details and to retest the exploit.
• Access to sensitive information: Ensure that access to sensitive information through debug interfaces like /proc/kmsg, perf, and debugfs explicitly requires administrator permission.

Educational Summary and Practical Invitation

• You have learned the importance of keeping most security reports public to ensure broader review and improve the quality of solutions.
• You have identified when to use the private security list, reserved only for urgent and easily exploitable vulnerabilities.
• You have understood the specific guidelines for AI-assisted reports, including the need for concise and verifiable reports.
• You have explored the new Linux kernel threat model, which defines which violations constitute a vulnerability.
• You have learned to distinguish which issues should not be automatically considered vulnerabilities.

To apply this knowledge, start following the new guidelines when reporting security bugs in the Linux kernel. Make sure to test and verify vulnerabilities before submitting a report. Use artificial intelligence not only to identify vulnerabilities but also to develop and test fixes.

Refer to the updated documentation for more details and to stay informed about the latest Linux kernel security practices.