Before reporting a bug make sure nobody else already reported it. The easiest way to do this is to search through the syzkaller mailing list, syzkaller-bugs mailing list and syzbot dashboard for key frames present in the kernel stack traces.
Please report found bugs to the Linux kernel maintainers. To find out the list of maintainers responsible for a particular kernel subsystem, use the get_maintainer.pl script: ./scripts/get_maintainer.pl -f guilty_file.c
. Please add syzkaller@googlegroups.com
to the CC list. Make sure to mention the exact kernel branch and revision where the bug occurred. Many kernel mailing lists reject HTML formatted messages, so use the plain text mode when sending the report.
Think of what you report. Today, Linux maintainers are overwhelmed with bug reports, so increasing the incoming flow won't help to fix all the bugs. The more actionable your report is, the higher the chance that it will be addressed. Note that people are more likely to care about kernel crashes (e.g. use-after-frees or panics) than of INFO: messages and such, unless it is clearly visible from the report what exactly is wrong. If there are stalls or hangs, only report them if they are frequent enough or have a reliable reproducer.
Overall, bugs without reproducers are way less likely to be triaged and fixed. If the bug is reproducible, include the reproducer (C source if possible, otherwise a syzkaller program) and the .config
you used for your kernel. If the reproducer is available only in the form of a syzkaller program, please link the instructions on how to execute them in your report. Check that the reproducer works if you run it manually. Syzkaller tries to simplify the reproducer, but the result might not be ideal. You can try to simplify or annotate the reproducer manually, that greatly helps kernel developers to figure out why the bug occurs.
If you want to get extra credit, you can try to understand the bug and develop a fix yourself. If you can't figure out the right fix, but have some understanding of the bug, please add your thoughts and conclusions to the report, that will save some time for kernel developers.
If you believe that a found bug poses potential security threat, consider following the instructions below. Note, that these instructions are a work-in-progress and based on my current understanding of the disclosure process. This instruction is now being discussed here.
If you don't want to deal with this complex disclosure process you can either:
security@kernel.org
. In this case it should be fixed in the upstream kernel, but there are no guarantees that the fix will be propagated to stable or distro kernels. The maximum embargo on this list is 7 days.secalert@redhat.com
) or SUSE (security@suse.com
). They should fix the bug, assign a CVE, and notify other vendors. The maximum embargo on these lists is 5 weeks.oss-security@lists.openwall.com
.If you want to deal with the disclosure yourself, read below.
The three main mailing lists for reporting and disclosing Linux kernel security issues are security@kernel.org
, linux-distros@vs.openwall.org
and oss-security@lists.openwall.com
. The links for the guidelines for these lists are below, please read them carefully before sending anything to these lists.
security@kernel.org
- https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.htmllinux-distros@vs.openwall.org
- http://oss-security.openwall.org/wiki/mailing-lists/distrososs-security@lists.openwall.com
- http://oss-security.openwall.org/wiki/mailing-lists/oss-securityTo report minor security bugs (such as local DOS or local info leak):
patchwork.kernel.org
, git.kernel.org
or github.com
) in the request.oss-security@lists.openwall.com
.To report major security bugs (such as LPE, remote DOS, remote info leak or RCE):
security@kernel.org
:security@kernel.org
members.linux-distros@vs.openwall.org
:linux-distros@vs.openwall.org
to make the CVE description public and roll out the updated kernels.oss-security@lists.openwall.com
:oss-security@lists.openwall.com
.A few notes:
security@kernel.org
and linux-distros@vs.openwall.org
.security@kernel.org
members and upstream maintainers, keep the linux-distros aware of the progress.oss-security@lists.openwall.com
. All of these should be on the same day, at worst.oss-security@lists.openwall.com
right away.A good example of an LPE announcement structure on oss-security@lists.openwall.com
can be found here, however the timeline doesn't look right there: public announcement should have occurred right after the patch was submitted to netdev.