Things don’t seem to be slowing down in kernel development world, even for old subsystems that should be “stable”. Here’s my “todo” mbox filtered for linux-usb stuff, that has come in in the past few weeks:

---Mutt: =todo [Msgs:1732/4807 Inc:2 78M]---

This is going to be a rough -rc cycle…

@gregkh My condolences.

The AI security reports are untied from any economics right now.

We are fixing stuff that no one ever uses and with preconditions that make harm unlikely. And then there are the few nuggets...

But sorting this out seems completely left to the projects once an AI finding survived the researchers' harness.

This is unbalanced. What's the back pressure here?

@gregkh I gave up a maintainership last week and I still seem to be endlessly busy :)

Ok, after a first cut at the "easy" ones that obviously fix a bug, or are an older version that got superseded by a newer submission:
```
---Mutt: =todo [Msgs:1094/4170 Inc:2 69M]---
```
still crazy though...

@icing I push back a lot, but refusing "obviously a bugfix" is hard, and I don't want to do that, it will just take time to grind through them all.

Like I've been saying for the past few months in talks, "It's going to be a long 18 months", and somehow that number doesn't seem to get shorter....

@gregkh Pushing back takes effort, sometimes more than fixing the bug oneself, true.

As long as the mirage of making money/fame this way persists, it will stay tricky.

@gregkh Wow. Just wow.

@ljs Good, then you can keep the maintainers endlessy busy :)

@gregkh almost 700 in a hour, I know a faster way, ctrl-a, shift-del, if it was something important they will mail again 😜

When it comes to those bugfixes which are not vulnerabilities, how bad are they?

I can absolutely imagine the possibility of a function which clearly misbehaves on specific input, but it’s uncertain whether there is any way to cause it to be called with those inputs. And if the conditions required to trigger the bug are impossible, then that would be one reason for a bug to be low priority.

Another possibility is a bug with minimal impact even if it does happen. For example if the impact is temporary and cosmetic, then it might be a low priority.

But I agree that if they are obviously fixing bugs they should be applied. I think it’s often the case that developing and releasing a correct fix for a bug is less work than figuring out whether it is exploitable.

@kasperd @icing It's a mix, some are fixing an issue that a user has with a specific hardware device, others fix for hardware that is coming soon, but the huge majority right now is static analysis tools that are finding really old minor things that can be triggered if you "hold it wrong". Those are vulnerabilities at our level.

We also had a rash of syzbot found things recently as they updated their tooling to go "one layer deeper" for many USB gadget and devices, so that's just "normal" fuzzers doing their good work that they have been doing for a long long time.

We don't care "if it's exploitable", that's impossible to determine, and kind of pointless for us to worry about most of the time. See my many talks on that very topic if you are curious (also my blog posts about CVE kernel stuff, which cover it as well.)

@aho ctrl-a is not a valid keystroke in my mutt config....

@gregkh The latest patch I reviewed made a change that looked sensible albeit was suboptimal in isolation, and then I looked at which implementation of the subsystem op is called on any platform that uses this driver and it turned out to just add dead code.

I really need to get around to writing an LSP-integrated review tool for this type of exploration if I ever start reviewing stuff more often. Must fight the temptation to lazily vibe-review the diff inline.

@gregkh ouch 😸 must be me who don't use mutt...