Proposal: preflight checklist/lint for AI-assisted Linux kernel bug reports

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,