Speakers
Description
Linux kernel bug reports vary widely in quality: some are duplicates
or false positives, while others describe exploitable vulnerabilities
or issues with little practical impact. Maintainers still need to
determine what is real, what matters, and what deserves attention
first.
At the same time, bug findings are increasingly fragmented across
different tools and workflows, including fuzzers, static analyzers,
human analysis, AI-assisted tools, and patch-review systems. For
example, Sashiko may uncover pre-existing bugs while reviewing
patches, but those findings can remain scattered across individual
review reports rather than being collected and tracked in one place.
We are developing a continuous Linux kernel bug monitoring and triage
platform. The platform aggregates findings from multiple sources, maps
them to kernel subsystems, and gives maintainers a view of currently
observed bugs affecting the code they maintain. For each finding, it
attempts to generate and execute a reproducer on a KASAN-enabled
kernel to help validate the report. It also assesses potential impact.
For example, whether a bug may enable privilege escalation or has
limited practical impact. Confirmed bugs can also include AI-generated
analysis and draft patches to help reduce the effort required to
understand and fix the issue.
Building on the mailing-list discussion, we would like to explore
what actionable kernel bug observability should look like. How should
heterogeneous bug signals be validated, prioritized, and presented to
subsystem maintainers? How can automated analysis help distinguish
important bugs from noise without creating yet another stream of
low-quality reports?