Q: What first steps should I take to confirm an AI-reported kernel bug? A: Build and boot the latest mainline or a recent release candidate and test the latest stable or LTS branch if possible. Note exact kernel versions and config options and try to produce a minimal reproducer or a clear static-analysis path for static-only findings. Q: How do I check if an AI-reported finding is already known or fixed? A: Search lore.kernel.org for the file, function, or error text and scan recent commits for “Fixes:” lines that touch the code. Also check subsystem mailing list archives and syzbot reports, and reply to an existing thread with new data instead of starting a duplicate. Q: When should I use public mailing lists versus private security channels? A: Public is the default: send to the subsystem list and maintainers from the MAINTAINERS file so others can see and help. Use private security@kernel.org only for clear, unpatched, high-impact vulnerabilities that truly benefit from an embargo. Q: How important is it to include a patch with an AI-detected bug report? A: Proposing a fix, even a small one, adds real value; compile-test it, run basic runtime tests if you can, and follow kernel style with checkpatch.pl. Include a clear commit message explaining why and how, add “Fixes:” and “Reported-by:” tags where relevant, and send the patch via git send-email to the right lists. Q: What details must I include to make a report useful to maintainers? A: Provide a concise subject, environment details (kernel versions, distro, config), a minimal reproducer or exact static analysis path, expected versus actual behavior, and a clear impact and trigger description. Attach relevant logs such as oops traces or KASAN output and include the tool name, version, rule, and why the finding matters. Q: How do I find and CC the correct maintainers and lists? A: Run scripts/get_maintainer.pl on your patch to find recipients and CC the subsystem list(s) and relevant maintainers rather than only LKML. Group related changes into a focused series and ensure each patch is compile-tested before sending. Q: How can I decide whether an AI-found issue is a security bug? A: Assess whether the bug crosses a privilege boundary, allows code execution, causes a reliable information leak, or enables a DoS by an untrusted user—those are security-relevant. If it is a build-only nit, unreachable path, or an obsolete/unmaintained driver with no users, treat it as non-security and state your reasoning and limits. Q: What common mistakes should I avoid when reporting AI-detected issues? A: Avoid sending unbuilt LLM-written patches, filing the same unmodified report to multiple lists, sending AI-found nits to the private security list, omitting versions/logs/reproducers, or disappearing after sending. Follow a lightweight checklist—reproduce on current mainline, search lore.kernel.org, include impact and a tested patch, and follow up in-thread—as guidance on how to report AI-detected Linux kernel bugs.