[RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[Yuan Tan]

Hi all,

We would like to ask for feedback on a proposed workflow for reporting Linux
kernel bugs found by an LLM-assisted code auditing tool that we have
been developing since earlier this year.

Since February, we have been developing an LLM-driven kernel code auditing
tool called VEGA. It started as a side project, but the results became much
substantial than we expected: VEGA has found hundreds of valid bugs in Linux
kernel.

That immediately created a practical problem: we do not want to dump a large
pile of bug reports onto mail lists and annoy the maintainers.

The first thing we tried was to fix as many as we could ourselves. We
started working with a group of student volunteers. Most of them are
college students, so we have been training them, reviewing their patches,
and trying to build an internal review process before anything is sent to
the mailing list. The goal is to turn these findings into useful fixes, and
also to help new contributors grow into people who can reduce maintainer
workload instead of adding to it.

The process was not perfect. Some patches were not good enough, and we also
made some mistakes early on when deciding what should be called a security
issue.  Our internal review process has been improving with the help of the
community.

Since March, we picked up non-root triggerable bug first and have worked on
fixes for more than 100 validated kernel bugs. we especially want to thank
the students and professor who have helped a lot with this effort.

But the remaining queue is still too large for us to handle.

Recently Jamal pointed out problems around our tags. That made me realize
that we should probably stop treating this as an ad-hoc patch effort and
build something closer to syzbot: public, reproducible, trackable,
deduplicated, and useful to maintainers.

So this mail is an RFC for a VEGA reporting workflow.

The rough idea
==============

VEGA would have a public dashboard, similar to syzbot, and would
send selected bug reports to the relevant kernel mailing lists.

The goal is to send reports that contain enough information for maintainers
or other developers to pick up, understand, reproduce and fix the issue.

For each public report, we expect to include:

  - a description of the bug
  - the tested kernel tree and commit
  - the kernel config and environment
  - the crash log
  - a minimized user-space reproducer
  - the suspected introducing commit
  - a suggested fix patch

The suggested fix patch is meant to reduce maintainer burden. It still need
human review, but hopefully it can save a lot time from building a patch
from scratch.

What will be public
===================

All VEGA findings that we have evaluated as not having major security
impact can be published on the VEGA dashboard. The dashboard would make it
possible to see what VEGA found, whether the issue was reproduced, whether
a fix exists, whether it was reported to a mailing list, and whether it has
been fixed upstream.

For issues that we have validated as having possible serious security
impact, we will not publish it on the public dashboard before going through
the appropriate kernel security process.

Dumping everything onto the mailing list may be annoying. During the initial
stage, reports will be rate-limited and sent manually. We will check for
duplicates against lore/upstream, and make sure the issue is not already
fixed or reported.

Report identity and tags
========================

Each public VEGA report will have a stable identity, similar to
syzbot reports.

One possible format is:

  Reported-by: VEGA <vega+HASH@DOMAIN>
  Closes: <public dashboard URL>

=========

We would like to hear what maintainers think about this before we start
sending these reports.

We do not want VEGA to become another source of mailing list noise. The goal
is to make LLM-based bug finding transparent and useful, and to make sure
the reports come with enough context, reproducers, suggested fixes, and
tracking so that they reduce work rather than create more.

Thanks,
Yuan

Re: [RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[Paolo Abeni]

Hi,

On 7/8/26 11:22 AM, Yuan Tan wrote:
> The rough idea
> ==============
> 
> VEGA would have a public dashboard, similar to syzbot, and would
> send selected bug reports to the relevant kernel mailing lists.
> 
> The goal is to send reports that contain enough information for maintainers
> or other developers to pick up, understand, reproduce and fix the issue.
> 
> For each public report, we expect to include:
> 
>   - a description of the bug
>   - the tested kernel tree and commit
>   - the kernel config and environment
>   - the crash log
>   - a minimized user-space reproducer
>   - the suspected introducing commit
>   - a suggested fix patch
> 
> The suggested fix patch is meant to reduce maintainer burden. It still need
> human review, but hopefully it can save a lot time from building a patch
> from scratch.

Thanks for sharing. This sounds very interesting to me, modulo final
impact on the ML - overall load is severely increased since the LLM era,
while the maintainers pool not so much.

A few notes on top of my head:
- the amount/rate of reports is critical. The higher the rate, the
better need to be the reproducer and the suggested patch.
- the crash log should include the decoded stack trace.
- IIRC syzbot reports sharing is [always] human
moderated/limited/controlled. I think that is the correct default and I
hope it should be possible for you, too.
- it's not entirely clear to me who exactly is 'you' and would
appreciate more info about that.
- it would be great to discuss this topic in person, i.e. in the
upcoming NetDev.

Thanks,

Paolo

Re: [RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[Laurent Pinchart]

On Wed, Jul 08, 2026 at 02:22:47AM -0700, Yuan Tan wrote:
> Hi all,
> 
> We would like to ask for feedback on a proposed workflow for reporting Linux
> kernel bugs found by an LLM-assisted code auditing tool that we have
> been developing since earlier this year.
> 
> Since February, we have been developing an LLM-driven kernel code auditing
> tool called VEGA. It started as a side project, but the results became much
> substantial than we expected: VEGA has found hundreds of valid bugs in Linux
> kernel.
> 
> That immediately created a practical problem: we do not want to dump a large
> pile of bug reports onto mail lists and annoy the maintainers.
> 
> The first thing we tried was to fix as many as we could ourselves. We
> started working with a group of student volunteers. Most of them are
> college students, so we have been training them, reviewing their patches,
> and trying to build an internal review process before anything is sent to
> the mailing list. The goal is to turn these findings into useful fixes, and
> also to help new contributors grow into people who can reduce maintainer
> workload instead of adding to it.
> 
> The process was not perfect. Some patches were not good enough, and we also
> made some mistakes early on when deciding what should be called a security
> issue.  Our internal review process has been improving with the help of the
> community.
> 
> Since March, we picked up non-root triggerable bug first and have worked on
> fixes for more than 100 validated kernel bugs. we especially want to thank
> the students and professor who have helped a lot with this effort.
> 
> But the remaining queue is still too large for us to handle.
> 
> Recently Jamal pointed out problems around our tags. That made me realize
> that we should probably stop treating this as an ad-hoc patch effort and
> build something closer to syzbot: public, reproducible, trackable,
> deduplicated, and useful to maintainers.
> 
> So this mail is an RFC for a VEGA reporting workflow.
> 
> The rough idea
> ==============
> 
> VEGA would have a public dashboard, similar to syzbot, and would
> send selected bug reports to the relevant kernel mailing lists.
> 
> The goal is to send reports that contain enough information for maintainers
> or other developers to pick up, understand, reproduce and fix the issue.
> 
> For each public report, we expect to include:
> 
>   - a description of the bug
>   - the tested kernel tree and commit
>   - the kernel config and environment
>   - the crash log
>   - a minimized user-space reproducer
>   - the suspected introducing commit
>   - a suggested fix patch
> 
> The suggested fix patch is meant to reduce maintainer burden. It still need
> human review, but hopefully it can save a lot time from building a patch
> from scratch.

Will the information included in the public report (including the
suggested fix) be written by a human or an LLM ? In the latter case I
don't see how you could reasonably claim to reduce maintainer burden, so
that would be a big NACK as far as I'm concerned.

> What will be public
> ===================
> 
> All VEGA findings that we have evaluated as not having major security
> impact can be published on the VEGA dashboard. The dashboard would make it
> possible to see what VEGA found, whether the issue was reproduced, whether
> a fix exists, whether it was reported to a mailing list, and whether it has
> been fixed upstream.
> 
> For issues that we have validated as having possible serious security
> impact, we will not publish it on the public dashboard before going through
> the appropriate kernel security process.
> 
> Dumping everything onto the mailing list may be annoying. During the initial
> stage, reports will be rate-limited and sent manually. We will check for
> duplicates against lore/upstream, and make sure the issue is not already
> fixed or reported.
> 
> Report identity and tags
> ========================
> 
> Each public VEGA report will have a stable identity, similar to
> syzbot reports.
> 
> One possible format is:
> 
>   Reported-by: VEGA <vega+HASH@DOMAIN>
>   Closes: <public dashboard URL>
> 
> =========
> 
> We would like to hear what maintainers think about this before we start
> sending these reports.
> 
> We do not want VEGA to become another source of mailing list noise. The goal
> is to make LLM-based bug finding transparent and useful, and to make sure
> the reports come with enough context, reproducers, suggested fixes, and
> tracking so that they reduce work rather than create more.

-- 
Regards,

Laurent Pinchart

Re: [RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[Hillf Danton]

On Wed, Jul 08, 2026 at 02:22:47AM -0700, Yuan Tan wrote:
> Hi all,
> 
> We would like to ask for feedback on a proposed workflow for reporting Linux
> kernel bugs found by an LLM-assisted code auditing tool that we have
> been developing since earlier this year.
> 
> Since February, we have been developing an LLM-driven kernel code auditing
> tool called VEGA. It started as a side project, but the results became much
> substantial than we expected: VEGA has found hundreds of valid bugs in Linux
> kernel.
> 
> That immediately created a practical problem: we do not want to dump a large
> pile of bug reports onto mail lists and annoy the maintainers.
> 
Given the syzbot reports, I think less than 11 true vega reports a day will
not trigger a panic.

Re: [RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[Andrew Lunn]

> The rough idea
> ==============
> 
> VEGA would have a public dashboard, similar to syzbot, and would
> send selected bug reports to the relevant kernel mailing lists.
> 
> The goal is to send reports that contain enough information for maintainers
> or other developers to pick up, understand, reproduce and fix the issue.
> 
> For each public report, we expect to include:
> 
>   - a description of the bug
>   - the tested kernel tree and commit
>   - the kernel config and environment
>   - the crash log
>   - a minimized user-space reproducer
>   - the suspected introducing commit
>   - a suggested fix patch

It would be nice if you could try to parse the git logs for the driver
and extrapolate its age, and if it is still being actively Maintained
by somebody.

We see lots of LLM generated patches for theoretical bugs, mostly in
error paths, for drivers which are EOL, and it is unlikely anybody is
still using the hardware. Such patches waste Reviewer/Maintainer time.

Maybe even make this part of your triage process. Prioritise issues
found on newer, used drivers, over old likely unused drives.

      Andrew

Re: [RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs

[Greg KH]

On Wed, Jul 08, 2026 at 02:22:47AM -0700, Yuan Tan wrote:
> Hi all,
> 
> We would like to ask for feedback on a proposed workflow for reporting Linux
> kernel bugs found by an LLM-assisted code auditing tool that we have
> been developing since earlier this year.
> 
> Since February, we have been developing an LLM-driven kernel code auditing
> tool called VEGA. It started as a side project, but the results became much
> substantial than we expected: VEGA has found hundreds of valid bugs in Linux
> kernel.
> 
> That immediately created a practical problem: we do not want to dump a large
> pile of bug reports onto mail lists and annoy the maintainers.

True, which is why we all end up with long lists of issues/patches at
the moment.  The initial reaction is "we need a dashboard for everyone
to collab around!" like you did here, but I'd like to say this is not
the best thing to do at all.

syzbot can get away with a dashboard because someone is tending to it,
triaging the "serious" bugs before they become public, and only letting
the "would be nice to fix one day" type issues remain.  That's a huge
resource commitment that Google has made here, and that's great, but I
doubt that anyone else will have those resources to do this type of
thing.

Instead, let's just work to get these things fixed.  We all have
hundreds of patches/reports in our internal systems right now,
attempting to triage/rank/coordinate would just waste time.  In other
words, just grind through them, send patches out, and get these fixed.

I'm doing this now, and I know many others are as well.  We are all
running "different" tools, and so we find different issues, so we can
all just keep sending patches as we get them done.  It's going to take a
lot of effort (I've somehow convinced 8 interns to help me out with this
this summer), but once we get it done, we'll be much better off.

> The first thing we tried was to fix as many as we could ourselves. We
> started working with a group of student volunteers. Most of them are
> college students, so we have been training them, reviewing their patches,
> and trying to build an internal review process before anything is sent to
> the mailing list. The goal is to turn these findings into useful fixes, and
> also to help new contributors grow into people who can reduce maintainer
> workload instead of adding to it.
> 
> The process was not perfect. Some patches were not good enough, and we also
> made some mistakes early on when deciding what should be called a security
> issue.  Our internal review process has been improving with the help of the
> community.

That's great, keep it up!

> But the remaining queue is still too large for us to handle.
> 
> Recently Jamal pointed out problems around our tags. That made me realize
> that we should probably stop treating this as an ad-hoc patch effort and
> build something closer to syzbot: public, reproducible, trackable,
> deduplicated, and useful to maintainers.

Again, I think that effort is going to be larger than just getting the
patches fixed and pushed out.  It also turns into a central
point-of-failure, which is what we do not want to have at all for the
kernel.

But hey, I could be totally wrong.  Maybe some generous company that is
involved in unleashing this hell on us would be so kind as to pony up to
do the work to create this and help fix the issues that their tools are
finding.  Just like Google did in the past, there is precedent, but for
some reason people don't like learning from history...

It's going to be a long 18 months...

greg k-h