[ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Yuan Tan]

Hi all,

A month ago, I posted an RFC[1] to the mailing list proposing an automated
platform that validates AI-reported bugs and prepares draft fixes, and
later discussed the idea at the Netdev conference. After further
development, it is finally ready.

While preparing to send this email, I noticed that Roman has since started
a related discussion:
[MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process

It turns out this platform already addresses several of the needs raised
there.

The platform is available at:
https://bugtracker.nebusec.ai

It is currently hosted under my company's domain for convenience. I would
prefer to move it to a neutral, community-oriented domain once the project
name is settled.
Access is currently restricted to maintainers whose email addresses are
listed in the Linux kernel MAINTAINERS file.
For now, only bug reports from the net subsystem have been fully imported
and processed.

-------------------------------------------------------------------------

LLM-powered tools such as Sashiko and Claskiko produce a significant number
of false positives. Pre-existing bugs uncovered by these tools are also not
collected in one place and they remain scattered across individual review
reports.

To address this, like syzbot for fuzzer-found bugs, this platform provides
an **automated** tracking layer for AI-reported bugs, but goes further by
generating PoCs, running them in QEMU to produce crash logs, triaging
severity, and drafting patches. This requires no extra effort from
maintainers; instead, it may helps them understand and fix these bugs more
efficiently.


The platform offers the following capabilities:

1. Collect and Deduplicate

The platform ingests bug reports from multiple sources, including Sashiko,
Claskiko, and others. It deduplicates them and monitors mailing lists and
git history to track whether they have been fixed.

It also provides visibility into the Sashiko/Claskiko ingestion queue, so
users can see which reports are waiting to be collected and processed.


2. Verify by generating PoC and running it in QEMU

An agent attempts to generate a proof-of-concept for each bug to determine
whether it is a false positive. According to paper Patch-to-PoC[2] and
follow-up research, GPT-5.4 achieves up to a 95% success rate in generating
PoCs for genuinely exploitable bugs.

This makes PoC generation a strong signal: if a bug has no PoC, it is very
likely a false positive. And even in cases where a real bug is missed, the
difficulty of generating a PoC suggests it is unlikely to be practically
exploitable.


3. Draft Patch

The platform produces a draft patch to give maintainers a starting point
and suggested fix direction. These still require human review. Patches can
be downloaded via b4 am.

These patches are not sent to mailing lists to avoid adding AI-generated
noise.


4. Triage

Based on the PoC, the agent evaluates the conditions required to trigger
the bug, for example, whether it requires a namespace, root privileges, or
can be triggered by an unprivileged user.

Bugs that require root are generally less important, while those reachable
by unprivileged users are more likely to have real security impact.

If a bug can be triggered from namespace, it is still worth
paying attention to.
In particular, a bug should not be considered root-only merely because
triggering it requires CAP_NET_ADMIN in a network namespace. On systems
that allow unprivileged user namespaces, an ordinary user may be able to
create a user namespace, create a network namespace owned by it, and obtain
capabilities such as CAP_NET_ADMIN with respect to that namespace. Such
bugs may therefore still be reachable by an otherwise unprivileged local
user.

For example, this configuration has historically been available by default
on distributions such as Ubuntu 22.04 LTS and earlier.

Jamal previously offered some suggestions on this severity classification
scheme which I have not yet had time to implement; that will come in a
future update.


5. Chat with agent

Each bug page includes a chat interface for discussing the bug and its fix
with the agent.



Based on earlier feedback, the system is not fully public. Only email
addresses listed in the MAINTAINERS file are eligible to register, to
prevent bugs with potential security impact from being exposed publicly.

Jason’s idea of delegating fixes could also be implemented on this
platform. This is essentially what my volunteer bug-fixing team and I have
been doing over the past six months: anyone interested can pick up an issue
and try to fix it. 
Each subsystem’s maintainers could choose whether to make its issues
public. Making them public would also let potential reporters check whether
an issue is already known before submitting a new report.

Bugs are also categorized by subsystem, so after logging in, maintainers
see only the bugs relevant to the modules they maintain.


Welcome any suggestions:)  I will continue maintaining this system and
adding more features, not only out of personal interest, but also our
bug-fixing volunteer team is using it too.

We periodically burn tokens and run state-of-the-art models against the
full kernel source code, with the goal of finding security vulnerabilities
before attackers do. While I am not an expert in the net subsystem and
cannot review patches myself at this time, I still hope this platform can
be of help to the community.

If this system proves genuinely useful, I am happy to transfer project
ownership to the Linux Foundation or another neutral host.

Going forward, the platform will expose a public API so that other bug
finding research teams can submit their findings here for centralized
processing. We also plan to ingest syzbot-found bugs to provide them with
the same triage workflow.

P.S. I have been struggling to come up with a good name for this platform. A
few candidates I am considering are Palomar, Tengu, FixArc, and Ephemeris.
If anyone has a preference or a better suggestion, I would love to hear it.


Current Limitations

- For a tracked bug, the system currently only knows that a fix exists; it
does not yet distinguish between a patch that has been posted to the
mailing list and one that has already been merged.

- PoC generation and false-positive verification are not yet supported for
driver-related bugs.

- Unable to scrape Sashiko/Clashiko review reports that are still under embargo.

- Only net subsystem bugs from Sashiko and Claskiko have been imported with
a fully automated fix-detection pipeline so far. Bugs from other subsystems
are shown but may already be fixed. If other subsystem maintainers are
interested, I will prioritize adding support.


[1] https://lore.kernel.org/all/20260708092247.4188498-1-yuantan098@gmail.com/
[2] Juefei Pu, Xingyu Li, Zhengchuan Liang, et al. "Patch-to-PoC: A
Systematic Study of Agentic LLM Systems for Linux Kernel N-Day
Reproduction." arXiv:2602.07287, 2026. https://arxiv.org/abs/2602.07287


Thanks,
Yuan

Re: [ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Guenter Roeck]

On 8/30/26 04:55, Yuan Tan wrote:
> 
> Hi all,
> 
> A month ago, I posted an RFC[1] to the mailing list proposing an automated
> platform that validates AI-reported bugs and prepares draft fixes, and
> later discussed the idea at the Netdev conference. After further
> development, it is finally ready.
> 
> While preparing to send this email, I noticed that Roman has since started
> a related discussion:
> [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
> 
> It turns out this platform already addresses several of the needs raised
> there.
> 
> The platform is available at:
> https://bugtracker.nebusec.ai
> 
> It is currently hosted under my company's domain for convenience. I would
> prefer to move it to a neutral, community-oriented domain once the project
> name is settled.
> Access is currently restricted to maintainers whose email addresses are
> listed in the Linux kernel MAINTAINERS file.
> For now, only bug reports from the net subsystem have been fully imported
> and processed.
> 
> -------------------------------------------------------------------------
> 
> LLM-powered tools such as Sashiko and Claskiko produce a significant number

Is "Claskiko" misspelled ? I don't find a reference to it.

> of false positives. Pre-existing bugs uncovered by these tools are also not
> collected in one place and they remain scattered across individual review
> reports.
> 
> To address this, like syzbot for fuzzer-found bugs, this platform provides
> an **automated** tracking layer for AI-reported bugs, but goes further by
> generating PoCs, running them in QEMU to produce crash logs, triaging
> severity, and drafting patches. This requires no extra effort from
> maintainers; instead, it may helps them understand and fix these bugs more
> efficiently.
> 
> 
> The platform offers the following capabilities:
> 
> 1. Collect and Deduplicate
> 
> The platform ingests bug reports from multiple sources, including Sashiko,
> Claskiko, and others. It deduplicates them and monitors mailing lists and
> git history to track whether they have been fixed.
> 
> It also provides visibility into the Sashiko/Claskiko ingestion queue, so
> users can see which reports are waiting to be collected and processed.
> 
> 
> 2. Verify by generating PoC and running it in QEMU
> 
> An agent attempts to generate a proof-of-concept for each bug to determine
> whether it is a false positive. According to paper Patch-to-PoC[2] and
> follow-up research, GPT-5.4 achieves up to a 95% success rate in generating
> PoCs for genuinely exploitable bugs.
> 
> This makes PoC generation a strong signal: if a bug has no PoC, it is very
> likely a false positive. And even in cases where a real bug is missed, the
> difficulty of generating a PoC suggests it is unlikely to be practically
> exploitable.
> 

I think it is a mistake to claim that "Not exploitable / No PoC --> false
positive". Not all bugs are vulnerabilities, much less exploitable ones.

Guenter

> 
> 3. Draft Patch
> 
> The platform produces a draft patch to give maintainers a starting point
> and suggested fix direction. These still require human review. Patches can
> be downloaded via b4 am.
> 
> These patches are not sent to mailing lists to avoid adding AI-generated
> noise.
> 
> 
> 4. Triage
> 
> Based on the PoC, the agent evaluates the conditions required to trigger
> the bug, for example, whether it requires a namespace, root privileges, or
> can be triggered by an unprivileged user.
> 
> Bugs that require root are generally less important, while those reachable
> by unprivileged users are more likely to have real security impact.
> 
> If a bug can be triggered from namespace, it is still worth
> paying attention to.
> In particular, a bug should not be considered root-only merely because
> triggering it requires CAP_NET_ADMIN in a network namespace. On systems
> that allow unprivileged user namespaces, an ordinary user may be able to
> create a user namespace, create a network namespace owned by it, and obtain
> capabilities such as CAP_NET_ADMIN with respect to that namespace. Such
> bugs may therefore still be reachable by an otherwise unprivileged local
> user.
> 
> For example, this configuration has historically been available by default
> on distributions such as Ubuntu 22.04 LTS and earlier.
> 
> Jamal previously offered some suggestions on this severity classification
> scheme which I have not yet had time to implement; that will come in a
> future update.
> 
> 
> 5. Chat with agent
> 
> Each bug page includes a chat interface for discussing the bug and its fix
> with the agent.
> 
> 
> 
> Based on earlier feedback, the system is not fully public. Only email
> addresses listed in the MAINTAINERS file are eligible to register, to
> prevent bugs with potential security impact from being exposed publicly.
> 
> Jason’s idea of delegating fixes could also be implemented on this
> platform. This is essentially what my volunteer bug-fixing team and I have
> been doing over the past six months: anyone interested can pick up an issue
> and try to fix it.
> Each subsystem’s maintainers could choose whether to make its issues
> public. Making them public would also let potential reporters check whether
> an issue is already known before submitting a new report.
> 
> Bugs are also categorized by subsystem, so after logging in, maintainers
> see only the bugs relevant to the modules they maintain.
> 
> 
> Welcome any suggestions:)  I will continue maintaining this system and
> adding more features, not only out of personal interest, but also our
> bug-fixing volunteer team is using it too.
> 
> We periodically burn tokens and run state-of-the-art models against the
> full kernel source code, with the goal of finding security vulnerabilities
> before attackers do. While I am not an expert in the net subsystem and
> cannot review patches myself at this time, I still hope this platform can
> be of help to the community.
> 
> If this system proves genuinely useful, I am happy to transfer project
> ownership to the Linux Foundation or another neutral host.
> 
> Going forward, the platform will expose a public API so that other bug
> finding research teams can submit their findings here for centralized
> processing. We also plan to ingest syzbot-found bugs to provide them with
> the same triage workflow.
> 
> P.S. I have been struggling to come up with a good name for this platform. A
> few candidates I am considering are Palomar, Tengu, FixArc, and Ephemeris.
> If anyone has a preference or a better suggestion, I would love to hear it.
> 
> 
> Current Limitations
> 
> - For a tracked bug, the system currently only knows that a fix exists; it
> does not yet distinguish between a patch that has been posted to the
> mailing list and one that has already been merged.
> 
> - PoC generation and false-positive verification are not yet supported for
> driver-related bugs.
> 
> - Unable to scrape Sashiko/Clashiko review reports that are still under embargo.
> 
> - Only net subsystem bugs from Sashiko and Claskiko have been imported with
> a fully automated fix-detection pipeline so far. Bugs from other subsystems
> are shown but may already be fixed. If other subsystem maintainers are
> interested, I will prioritize adding support.
> 
> 
> [1] https://lore.kernel.org/all/20260708092247.4188498-1-yuantan098@gmail.com/
> [2] Juefei Pu, Xingyu Li, Zhengchuan Liang, et al. "Patch-to-PoC: A
> Systematic Study of Agentic LLM Systems for Linux Kernel N-Day
> Reproduction." arXiv:2602.07287, 2026. https://arxiv.org/abs/2602.07287
> 
> 
> Thanks,
> Yuan

Re: [ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Paolo Abeni]

On 8/31/26 9:08 PM, Guenter Roeck wrote:
> On 8/30/26 04:55, Yuan Tan wrote:
>> LLM-powered tools such as Sashiko and Claskiko produce a significant number
> 
> Is "Claskiko" misspelled ? I don't find a reference to it.
Clashiko is the "informal" name for the sashiko instance running on the
networking subsystem CI. Since it's ongoing under constant improvements
and changes due to a lot of effort from Jakub, there is no formal
documentation on it.

/P

Re: [ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Jan Kara]

Hi,

On Sun 30-08-26 04:55:45, Yuan Tan wrote:
> A month ago, I posted an RFC[1] to the mailing list proposing an automated
> platform that validates AI-reported bugs and prepares draft fixes, and
> later discussed the idea at the Netdev conference. After further
> development, it is finally ready.
> 
> While preparing to send this email, I noticed that Roman has since started
> a related discussion:
> [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
> 
> It turns out this platform already addresses several of the needs raised
> there.
> 
> The platform is available at:
> https://bugtracker.nebusec.ai
> 
> It is currently hosted under my company's domain for convenience. I would
> prefer to move it to a neutral, community-oriented domain once the project
> name is settled.
> Access is currently restricted to maintainers whose email addresses are
> listed in the Linux kernel MAINTAINERS file.
> For now, only bug reports from the net subsystem have been fully imported
> and processed.

I was playing with this for a while and this looks useful. Some notes I have:

1) When you download the patch, it has 'From' field set to some value (I've
actually seen different values in different patches). Perhaps it would make
sense to automatically set From to the person downloading the patch (or
maybe value configured in user's profile)?

2) Based on current state of the kernel doc, the patches should contain
"Assisted-by: LLM" tag although I understand that might be controversial.

3) It would be nice if you could "assign" the report to yourself - i.e.,
you've decided to handle this and don't want co-maintainers to waste time
on it anymore.

Thanks for putting together the service.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Yuan Tan]

On 8/31/26 12:08, Guenter Roeck wrote:
> On 8/30/26 04:55, Yuan Tan wrote:
>>
>> Hi all,
>>
>> A month ago, I posted an RFC[1] to the mailing list proposing an
>> automated
>> platform that validates AI-reported bugs and prepares draft fixes, and
>> later discussed the idea at the Netdev conference. After further
>> development, it is finally ready.
>>
>> While preparing to send this email, I noticed that Roman has since
>> started
>> a related discussion:
>> [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel
>> process
>>
>> It turns out this platform already addresses several of the needs raised
>> there.
>>
>> The platform is available at:
>> https://bugtracker.nebusec.ai
>>
>> It is currently hosted under my company's domain for convenience. I
>> would
>> prefer to move it to a neutral, community-oriented domain once the
>> project
>> name is settled.
>> Access is currently restricted to maintainers whose email addresses are
>> listed in the Linux kernel MAINTAINERS file.
>> For now, only bug reports from the net subsystem have been fully
>> imported
>> and processed.
>>
>> -------------------------------------------------------------------------
>>
>>
>> LLM-powered tools such as Sashiko and Claskiko produce a significant
>> number
>
> Is "Claskiko" misspelled ? I don't find a reference to it.
>
>> of false positives. Pre-existing bugs uncovered by these tools are
>> also not
>> collected in one place and they remain scattered across individual
>> review
>> reports.
>>
>> To address this, like syzbot for fuzzer-found bugs, this platform
>> provides
>> an **automated** tracking layer for AI-reported bugs, but goes
>> further by
>> generating PoCs, running them in QEMU to produce crash logs, triaging
>> severity, and drafting patches. This requires no extra effort from
>> maintainers; instead, it may helps them understand and fix these bugs
>> more
>> efficiently.
>>
>>
>> The platform offers the following capabilities:
>>
>> 1. Collect and Deduplicate
>>
>> The platform ingests bug reports from multiple sources, including
>> Sashiko,
>> Claskiko, and others. It deduplicates them and monitors mailing lists
>> and
>> git history to track whether they have been fixed.
>>
>> It also provides visibility into the Sashiko/Claskiko ingestion
>> queue, so
>> users can see which reports are waiting to be collected and processed.
>>
>>
>> 2. Verify by generating PoC and running it in QEMU
>>
>> An agent attempts to generate a proof-of-concept for each bug to
>> determine
>> whether it is a false positive. According to paper Patch-to-PoC[2] and
>> follow-up research, GPT-5.4 achieves up to a 95% success rate in
>> generating
>> PoCs for genuinely exploitable bugs.
>>
>> This makes PoC generation a strong signal: if a bug has no PoC, it is
>> very
>> likely a false positive. And even in cases where a real bug is
>> missed, the
>> difficulty of generating a PoC suggests it is unlikely to be practically
>> exploitable.
>>
>
> I think it is a mistake to claim that "Not exploitable / No PoC --> false
> positive". Not all bugs are vulnerabilities, much less exploitable ones.
>
> Guenter
>

Thanks, that is a good distinction. I think my wording here was misleading.

By “PoC”, I do not mean an exploit demonstrating security impact or
privilege escalation. The PoC generated at this stage is only intended
to reproduce the reported bug. For example, by triggering a KASAN
report, a kernel crash, or another observable runtime failure.

So the purpose of this step is primarily to validate reachability:
whether there exists a concrete execution path that causes the reported
bug to manifest at runtime.

This is substantially easier than exploit generation, especially with
sanitizer feedback available. More importantly, if the LLM has explored
all reachable paths relevant to the reported bug and none of them can
trigger the reported behavior, then we consider the report very likely
to be a false positive. 

In practice, of course, failure to generate a PoC is not formal proof
that the bug does not exist, but failing to find a triggering path after
exploring the relevant reachable paths still provides useful evidence
that the report may be a false positive.

I should change the text to distinguish a reproduction PoC from an
exploit PoC and avoid equating “not exploitable” with “false positive.”

Separately, we have also built a system for analyzing exploitability,
primarily whether a bug can be turned into a local privilege escalation.
This is a different stage from the reproduction PoC described above. We
can integrate that analysis into the platform as well, although it will
take some additional time to do so. In the meantime, we should be able
to import some of the existing analysis results first.

Yuan

>>
>> 3. Draft Patch
>>
>> The platform produces a draft patch to give maintainers a starting point
>> and suggested fix direction. These still require human review.
>> Patches can
>> be downloaded via b4 am.
>>
>> These patches are not sent to mailing lists to avoid adding AI-generated
>> noise.
>>
>>
>> 4. Triage
>>
>> Based on the PoC, the agent evaluates the conditions required to trigger
>> the bug, for example, whether it requires a namespace, root
>> privileges, or
>> can be triggered by an unprivileged user.
>>
>> Bugs that require root are generally less important, while those
>> reachable
>> by unprivileged users are more likely to have real security impact.
>>
>> If a bug can be triggered from namespace, it is still worth
>> paying attention to.
>> In particular, a bug should not be considered root-only merely because
>> triggering it requires CAP_NET_ADMIN in a network namespace. On systems
>> that allow unprivileged user namespaces, an ordinary user may be able to
>> create a user namespace, create a network namespace owned by it, and
>> obtain
>> capabilities such as CAP_NET_ADMIN with respect to that namespace. Such
>> bugs may therefore still be reachable by an otherwise unprivileged local
>> user.
>>
>> For example, this configuration has historically been available by
>> default
>> on distributions such as Ubuntu 22.04 LTS and earlier.
>>
>> Jamal previously offered some suggestions on this severity
>> classification
>> scheme which I have not yet had time to implement; that will come in a
>> future update.
>>
>>
>> 5. Chat with agent
>>
>> Each bug page includes a chat interface for discussing the bug and
>> its fix
>> with the agent.
>>
>>
>>
>> Based on earlier feedback, the system is not fully public. Only email
>> addresses listed in the MAINTAINERS file are eligible to register, to
>> prevent bugs with potential security impact from being exposed publicly.
>>
>> Jason’s idea of delegating fixes could also be implemented on this
>> platform. This is essentially what my volunteer bug-fixing team and I
>> have
>> been doing over the past six months: anyone interested can pick up an
>> issue
>> and try to fix it.
>> Each subsystem’s maintainers could choose whether to make its issues
>> public. Making them public would also let potential reporters check
>> whether
>> an issue is already known before submitting a new report.
>>
>> Bugs are also categorized by subsystem, so after logging in, maintainers
>> see only the bugs relevant to the modules they maintain.
>>
>>
>> Welcome any suggestions:)  I will continue maintaining this system and
>> adding more features, not only out of personal interest, but also our
>> bug-fixing volunteer team is using it too.
>>
>> We periodically burn tokens and run state-of-the-art models against the
>> full kernel source code, with the goal of finding security
>> vulnerabilities
>> before attackers do. While I am not an expert in the net subsystem and
>> cannot review patches myself at this time, I still hope this platform
>> can
>> be of help to the community.
>>
>> If this system proves genuinely useful, I am happy to transfer project
>> ownership to the Linux Foundation or another neutral host.
>>
>> Going forward, the platform will expose a public API so that other bug
>> finding research teams can submit their findings here for centralized
>> processing. We also plan to ingest syzbot-found bugs to provide them
>> with
>> the same triage workflow.
>>
>> P.S. I have been struggling to come up with a good name for this
>> platform. A
>> few candidates I am considering are Palomar, Tengu, FixArc, and
>> Ephemeris.
>> If anyone has a preference or a better suggestion, I would love to
>> hear it.
>>
>>
>> Current Limitations
>>
>> - For a tracked bug, the system currently only knows that a fix
>> exists; it
>> does not yet distinguish between a patch that has been posted to the
>> mailing list and one that has already been merged.
>>
>> - PoC generation and false-positive verification are not yet
>> supported for
>> driver-related bugs.
>>
>> - Unable to scrape Sashiko/Clashiko review reports that are still
>> under embargo.
>>
>> - Only net subsystem bugs from Sashiko and Claskiko have been
>> imported with
>> a fully automated fix-detection pipeline so far. Bugs from other
>> subsystems
>> are shown but may already be fixed. If other subsystem maintainers are
>> interested, I will prioritize adding support.
>>
>>
>> [1]
>> https://lore.kernel.org/all/20260708092247.4188498-1-yuantan098@gmail.com/
>> [2] Juefei Pu, Xingyu Li, Zhengchuan Liang, et al. "Patch-to-PoC: A
>> Systematic Study of Agentic LLM Systems for Linux Kernel N-Day
>> Reproduction." arXiv:2602.07287, 2026. https://arxiv.org/abs/2602.07287
>>
>>
>> Thanks,
>> Yuan
>

Re: [ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Yuan Tan]

On 9/2/26 08:10, Jan Kara wrote:
> Hi,
>
> On Sun 30-08-26 04:55:45, Yuan Tan wrote:
>> A month ago, I posted an RFC[1] to the mailing list proposing an automated
>> platform that validates AI-reported bugs and prepares draft fixes, and
>> later discussed the idea at the Netdev conference. After further
>> development, it is finally ready.
>>
>> While preparing to send this email, I noticed that Roman has since started
>> a related discussion:
>> [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
>>
>> It turns out this platform already addresses several of the needs raised
>> there.
>>
>> The platform is available at:
>> https://bugtracker.nebusec.ai
>>
>> It is currently hosted under my company's domain for convenience. I would
>> prefer to move it to a neutral, community-oriented domain once the project
>> name is settled.
>> Access is currently restricted to maintainers whose email addresses are
>> listed in the Linux kernel MAINTAINERS file.
>> For now, only bug reports from the net subsystem have been fully imported
>> and processed.
> I was playing with this for a while and this looks useful. Some notes I have:
>
> 1) When you download the patch, it has 'From' field set to some value (I've
> actually seen different values in different patches). Perhaps it would make
> sense to automatically set From to the person downloading the patch (or
> maybe value configured in user's profile)?
>
Fixed!
>
> 2) Based on current state of the kernel doc, the patches should contain
> "Assisted-by: LLM" tag although I understand that might be controversial.
Fixed! 
>
> 3) It would be nice if you could "assign" the report to yourself - i.e.,
> you've decided to handle this and don't want co-maintainers to waste time
> on it anymore.

This feature is ready now. Our fixing team will also assign bugs to
themselves. Feel free to remove their names if you think it would be
better for you to fix a particular bug yourself. Our team definitely
won’t know this part of the code as well as the maintainers do, and
reviewing our patches may sometimes take more effort than fixing the bug
directly.

As for patch generation, I’ll make some adjustments. This is indeed
because I explicitly asked the llm in the prompt to follow the reverse
Christmas tree style.

Also, I haven’t had a chance yet to enable fix-status tracking or import
the Sashiko bug reports for the fs subsystem. So far, I’ve only finished
this for net, as cleaning up and normalizing all the data has been quite
a bit of work.

Some fs bugs may still be outside the threat model, such as those
requiring a corrupted or malicious filesystem to trigger. I haven’t
filtered those out yet.

Over the next couple of days, I’ll first run the fix-status detection
for the filesystem bugs and try to reduce as much unnecessary work for
you as possible.

Yuan

>
> Thanks for putting together the service.
>
> 								Honza

Re: [ANNOUNCE] A Syzbot-style Platform for Verifying and Fixing LLM-reported Bugs

[Yuan Tan]

On 8/30/26 04:55, Yuan Tan wrote:
> Hi all,
>
> A month ago, I posted an RFC[1] to the mailing list proposing an automated
> platform that validates AI-reported bugs and prepares draft fixes, and
> later discussed the idea at the Netdev conference. After further
> development, it is finally ready.
>
> While preparing to send this email, I noticed that Roman has since started
> a related discussion:
> [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
>
> It turns out this platform already addresses several of the needs raised
> there.
>
> The platform is available at:
> https://bugtracker.nebusec.ai
>
> It is currently hosted under my company's domain for convenience. I would
> prefer to move it to a neutral, community-oriented domain once the project
> name is settled.
> Access is currently restricted to maintainers whose email addresses are
> listed in the Linux kernel MAINTAINERS file.
> For now, only bug reports from the net subsystem have been fully imported
> and processed.
>
> -------------------------------------------------------------------------
>
> LLM-powered tools such as Sashiko and Claskiko produce a significant number
> of false positives. Pre-existing bugs uncovered by these tools are also not
> collected in one place and they remain scattered across individual review
> reports.
>
> To address this, like syzbot for fuzzer-found bugs, this platform provides
> an **automated** tracking layer for AI-reported bugs, but goes further by
> generating PoCs, running them in QEMU to produce crash logs, triaging
> severity, and drafting patches. This requires no extra effort from
> maintainers; instead, it may helps them understand and fix these bugs more
> efficiently.
>
>
> The platform offers the following capabilities:
>
> 1. Collect and Deduplicate
>
> The platform ingests bug reports from multiple sources, including Sashiko,
> Claskiko, and others. It deduplicates them and monitors mailing lists and
> git history to track whether they have been fixed.
>
> It also provides visibility into the Sashiko/Claskiko ingestion queue, so
> users can see which reports are waiting to be collected and processed.
>
>
> 2. Verify by generating PoC and running it in QEMU
>
> An agent attempts to generate a proof-of-concept for each bug to determine
> whether it is a false positive. According to paper Patch-to-PoC[2] and
> follow-up research, GPT-5.4 achieves up to a 95% success rate in generating
> PoCs for genuinely exploitable bugs.
>
> This makes PoC generation a strong signal: if a bug has no PoC, it is very
> likely a false positive. And even in cases where a real bug is missed, the
> difficulty of generating a PoC suggests it is unlikely to be practically
> exploitable.
>
>
> 3. Draft Patch
>
> The platform produces a draft patch to give maintainers a starting point
> and suggested fix direction. These still require human review. Patches can
> be downloaded via b4 am.
>
> These patches are not sent to mailing lists to avoid adding AI-generated
> noise.
>
>
> 4. Triage
>
> Based on the PoC, the agent evaluates the conditions required to trigger
> the bug, for example, whether it requires a namespace, root privileges, or
> can be triggered by an unprivileged user.
>
> Bugs that require root are generally less important, while those reachable
> by unprivileged users are more likely to have real security impact.
>
> If a bug can be triggered from namespace, it is still worth
> paying attention to.
> In particular, a bug should not be considered root-only merely because
> triggering it requires CAP_NET_ADMIN in a network namespace. On systems
> that allow unprivileged user namespaces, an ordinary user may be able to
> create a user namespace, create a network namespace owned by it, and obtain
> capabilities such as CAP_NET_ADMIN with respect to that namespace. Such
> bugs may therefore still be reachable by an otherwise unprivileged local
> user.
>
> For example, this configuration has historically been available by default
> on distributions such as Ubuntu 22.04 LTS and earlier.
>
> Jamal previously offered some suggestions on this severity classification
> scheme which I have not yet had time to implement; that will come in a
> future update.
>
>
> 5. Chat with agent
>
> Each bug page includes a chat interface for discussing the bug and its fix
> with the agent.
>
>
>
> Based on earlier feedback, the system is not fully public. Only email
> addresses listed in the MAINTAINERS file are eligible to register, to
> prevent bugs with potential security impact from being exposed publicly.
>
> Jason’s idea of delegating fixes could also be implemented on this
> platform. This is essentially what my volunteer bug-fixing team and I have
> been doing over the past six months: anyone interested can pick up an issue
> and try to fix it. 
> Each subsystem’s maintainers could choose whether to make its issues
> public. Making them public would also let potential reporters check whether
> an issue is already known before submitting a new report.
>
> Bugs are also categorized by subsystem, so after logging in, maintainers
> see only the bugs relevant to the modules they maintain.
>
>
> Welcome any suggestions:)  I will continue maintaining this system and
> adding more features, not only out of personal interest, but also our
> bug-fixing volunteer team is using it too.
>
> We periodically burn tokens and run state-of-the-art models against the
> full kernel source code, with the goal of finding security vulnerabilities
> before attackers do. While I am not an expert in the net subsystem and
> cannot review patches myself at this time, I still hope this platform can
> be of help to the community.
>
> If this system proves genuinely useful, I am happy to transfer project
> ownership to the Linux Foundation or another neutral host.
>
> Going forward, the platform will expose a public API so that other bug
> finding research teams can submit their findings here for centralized
> processing. We also plan to ingest syzbot-found bugs to provide them with
> the same triage workflow.
>
> P.S. I have been struggling to come up with a good name for this platform. A
> few candidates I am considering are Palomar, Tengu, FixArc, and Ephemeris.
> If anyone has a preference or a better suggestion, I would love to hear it.
>
>
> Current Limitations
>
> - For a tracked bug, the system currently only knows that a fix exists; it
> does not yet distinguish between a patch that has been posted to the
> mailing list and one that has already been merged.
>
> - PoC generation and false-positive verification are not yet supported for
> driver-related bugs.
>
> - Unable to scrape Sashiko/Clashiko review reports that are still under embargo.
>
> - Only net subsystem bugs from Sashiko and Claskiko have been imported with
> a fully automated fix-detection pipeline so far. Bugs from other subsystems
> are shown but may already be fixed. If other subsystem maintainers are
> interested, I will prioritize adding support.
>
>
> [1] https://lore.kernel.org/all/20260708092247.4188498-1-yuantan098@gmail.com/
> [2] Juefei Pu, Xingyu Li, Zhengchuan Liang, et al. "Patch-to-PoC: A
> Systematic Study of Agentic LLM Systems for Linux Kernel N-Day
> Reproduction." arXiv:2602.07287, 2026. https://arxiv.org/abs/2602.07287
>
>
> Thanks,
> Yuan
>

A couple of updates since my last email:

Previously, the bug list was not automatically filtered based on the
maintainer’s subsystems in the MAINTAINERS file after login. This has
now been fixed.

Also, a quick update for netdev:

We recently ran exploitability analysis on several hundred bugs and
imported the results into the tracker, so you can now directly see which
bugs appear to have higher security impact.

We identified 55 bugs that can be used for local privilege escalation.
The good news is that 46 of them have already been fixed, while 9 are
still unfixed. Fortunately, 8 of those 9 require |CONFIG_USER_NS=y| to
be exploitable.

I’m especially proud that students on my team contributed 34 of the
patches for those fixes, and I’m very grateful to the maintainers for
all the reviews and guidance. Once we finish the patches we’re currently
looking at, we’ll start working on these newly identified
privilege-escalation bugs.

The exploitability analysis still has to be run manually and is not yet
integrated into the system. Once the full pipeline is integrated, it
should make it much easier to see which bugs pose a greater security risk.

So although the LLM has found a large number of bugs, only a very small
fraction of them appear to be usable for local privilege escalation.

If any maintainers outside netdev are interested in using the tracker,
just let me know. I can prioritize importing the fixed bugs and Sashiko
findings for those subsystems first. Cleaning and importing the data
takes some time.