Hello, I understand that AI-assisted vulnerability and bug reports have recently become a burden for kernel maintainers, especially when reports are duplicated, unverified, or lack enough technical detail to be actionable.
I would like to suggest a lightweight “preflight” process for AI-assisted bug reports. The goal is not to replace the existing Linux kernel email workflow, nor to move kernel development into a web-based ticket system. Instead, the idea is to add a simple validation layer before a report reaches maintainers. For AI-assisted reports, the submitter could be required to include a structured checklist such as: AI-assisted bug report checklist: - Kernel version: - Commit hash: - Architecture: - Kernel config: - Affected subsystem / file / function: - Reproducer: - Reproduction rate: - Full dmesg / KASAN / UBSAN / lockdep / syzkaller log: - Checked latest mainline: yes/no - Checked stable trees: yes/no - Checked lore.kernel.org for duplicates: yes/no - Existing patch found: yes/no - Why this is considered a security issue: - Impact assessment: - Suggested fix or mitigation: - Human verification performed: yes/no Reports that do not include basic information such as a tested commit, reproducer, full logs, duplicate search summary, and existing-patch check could be automatically rejected or redirected before maintainers spend time on them. This could be implemented in a few possible ways: 1. A simple web form that outputs a properly formatted plain-text report. 2. A local command-line tool, similar in spirit to checkpatch.pl. 3. A report.yaml / report.txt format with a validator. 4. A mail bot that replies automatically when mandatory fields are missing. A local tool may fit the kernel workflow better than a centralized web form, since it avoids dependence on Google Forms, GitHub Issues, or any specific hosted service. For example: $ kernel-bug-report-lint report.txt logs/ [FAIL] No tested commit hash [FAIL] No reproducer [WARN] No lore.kernel.org duplicate search summary [WARN] Impact says "privilege escalation" but no reachable path is described [PASS] KASAN log included [PASS] kernel config included The key principle would be: If AI was used to find the bug, AI or automation should also be used by the reporter to perform initial triage before sending the report to maintainers. In other words, AI-assisted reports should include AI-assisted or human-assisted triage results, not just an unverified “this may be a vulnerability” claim. This would reduce duplicate and low-quality reports while preserving the existing mailing-list-based development process. This proposal is intentionally small. It does not require maintainers to pay for LLM APIs or run an AI system themselves. The cost of AI-based analysis should remain on the reporter side. The kernel project would only define the minimum structure and validation rules for acceptable AI-assisted reports. Thank you for considering the idea. Best regards,
