Re: ZDI-CAN-33367: New Vulnerability Report

[Willy Tarreau <w@1wt.eu>]

On Thu, Oct 22, 2026 at 06:51:09PM +0000, zdi-disclosures@trendmicro.com wrote:
> > > I had to cut this report. Way too long, I could not see a patch in it.
> >
> > Right. For future reports: please review the documentation on how to
> > share such findings:
> >
> > https://docs.kernel.org/process/security-bugs.html
> 
> We've probably submitted nearly 1000 cases to kernel over the last ten years.
> 
> How those cases are formatted today is essentially the same as the way they were
> formatted 10+ years ago aside from the changes you asked for in the past, but
> for the most part you've never had a problem with the way they were formatted
> until recently.
>
> I may be mistaken here, but I searched our mailbox and this is the first time
> I'm seeing the references to documentation on submitting findings to you.

As one having read many of them I'd say they're long but reasonably complete
in terms of descriptions, and barring the usual boring email-notice footer
etc they're not excessive.

What Willem's comment above translates however, is what we've been explaining
many times over the last months, which is that maintainers need a patch to
start from. Reading a patch is fast for a developer. Reading a convuluted
explanation of "if A does this while B does that then C might notice" is
much more difficult. Also keep in mind that not that many developers are
english natives, and code is much more universal than a given tongue. You
can more quickly think "ah OK I see what they're trying to do" while reading
an extra "if" block while a long description is much harder to grasp.

> We will have some discussions internally, but in the meantime, we will send the cases to you as we always have.
> If you don't want to do anything with it, that's fine too. We will release the findings at rejection, or 120 days.
> Whichever comes first.

The main problem we're having is that it's not possible to have anyone on
your side nor the reporter test a patch. But I won't rehash this, it's not
new, but *this* is what makes your reports way more painful to deal with
than many other ones. You (unvoluntarily it seems) act as an insulation
layer between reporters and develoeprs and that really doesn't help.

> Weird that Red Hat is on this email... Greg once told me he had no idea who those people
> were and asked that they be removed from security reports. I will probably get in touch with
> them again to discuss reporting.
> 
> We understand that your workflow has increased because of AI... and we are in the same boat.

Indeed but we also adapted our processes to scale better. You probably
underestimate the load here, just today we received more than 30 different
reports that need to be evaluated by people who also have a job and other
things to do, so it's understandable that they absolutely need to spend
the least possible time reading reports and exchanging with reporters.
While we're *reading* a report, others come.

That's also why we asked to systematically Cc maintainers (which you're
doing now, although I'm seeing public lists so s@k.o isn't needed in this
case, as documented), because we were spending 75% of our triage time
reading reports, calling get-maintainers, forwarding etc. We all need to
scale to adapt to the increased load caused by AI. And for maintainers,
many bugs look the same and there are many duplicates. Nothing more
frustrating than spending 10 minutes on a report to see that it describes
something fixed the week before, or that when they write a patch, they
get the usual "we can't test" response.

> The snide remarks and hostilities aren't new from your side, but we are doing
> our best with the people we have.

I personally have nothing against the persons we've been communicating
with, they seem restricted by bureaucratic processes they have no handle
on and are doing their best. However if you want to *really* help:
  - arrange your processes so that your reporters propose a tested patch,
    they're on the side where the code was analyzed and stressed ;

  - make it possible to exchange with the reporter. At least for some
    of them, maybe with a check box "Keep me CCed in communications
    with maintainers" and explain why we ask for this.

> I get the feeling that even if we were to update our report formatting to match your documentation
> It still wouldn't be enough because we aren't going to provide you with patches.

Sure ;-)

> That's just the way it is.
> It's not my call, and it's overhead we cannot support.

We're not asking you to write and test the patches yourself, just to at
least encourage reporters to do this and explain also why it's better
for the recognition of their work. We did it in our doc and it works.
The formatting is often wrong, etc but that's things we have to improve
on our side with better and clearer documentation about the various
possible options to submit a report. It just shows that when reporters
are asked to provide a fix, they're willing to do so. Please *try* on
your side. Even if only half of your reports came with a tested patch
from the reporter, it would be a nice improvement.

> In the same token, I know that you rely on a lot of contributors
> to get these bugs fixed... that's not lost on us.

Given the current load we have no other choice. Especially when many of
the reports are for drivers, protocols or file systems that maybe only
10 people use on the planet and cannot be triggered on any sanely managed
production system. Also with AI-based bug searching, it's very common to
see the LLM ditch its report when trying to write the patch because it
suddenly realizes how broken the report is, so that's a nice way to
filter on the reporter's side before initial submission.

So yes we're in the same boat in front of the AI cannon, but in the end
we have developers that are feeling that your service encourages incomplete
reports to be sent that do not follow our docuemnted rules and these
reports represent a huge overhead these days (but admittedly significantly
less for triage people than a few months ago, and I'm already grateful of
the progress you made in that direction).

Please try to push again to modernize your processes by involving the
reporter a bit more. You'll see that it will mostly be positively
received. Many of our first-time reporters come back with better
reports next times so I don't think we're asking too much.

Willy