Thread by @spendergrsec

Vibe coding has no place in Linux kernel maintenance. The vulnerability inserted into 5 LTS kernels at once apparently without any review is yet another instance of AUTOSEL fallout, here with the "new" LLM-powered version. Sources: lwn.net/Articles/10202… lore.kernel.org/all/2025050522…

I think good questions to ask when someone reports a vulnerability or regression caused by an incorrect backport are: can you articulate a reason why you backported this change? what review did you perform on the change to ensure it's appropriate for the kernel it's applied to?

I've reported a number of issues, and it feels like I'm just subsidizing broken processes because these two questions never get asked, so the root of the problem is never solved. It's boggling to me even that the person involved never even chimes in to suggest a revert...

knowing full well the amount of non-automated effort that went into the backport and that the reason for its selection was automated.

Like, when you know the only effort you put into the backport was "git cherry-pick <id>", didn't even check to see if the config option was present, lacked the awareness/memory of changes to these mitigations, what are you doing making changes to the code?

Further, I imagine AUTOSEL questions are asked once to select candidates, and then the results are used via cherry-pick globally back as far as it can go cleanly absent any other metadata restricting it. Wrong design that will keep producing wrong results.

I've seen lots of complaints about it from other kernel devs, but it doesn't seem like anything's fundamentally changed, and this new version seems even worse than before (and even worse than that if the results are just blindly trusted).

There seems to be a message communicated by stable policies that backports are "safe" and don't require involvement of someone knowledgeable with the code being modified if clean cherry-picks are possible. The only involvement knowledgeable people would have is being CC'd...

on a mail about the patch being queued for some stable kernel, with a few days given for review before the kernels are published. But importantly, the people CC'd on these mails haven't necessarily signed up for doing anything related to stable kernels, so no response...

doesn't necessarily mean review was done, and the CC list is limited to the people identified by the commit.

This isn't a new discussion by any stretch, it keeps coming up because the problems keep cropping up. See for instance here: social.kernel.org/notice/AmeaMpX…

@Dave_Maynor it's necessarily job security for anyone who has to clean up the mess, it's just an understaffed group that knowing it can't force unpaid people to review things they didn't ask for in kernels they didn't sign up for, has to get "creative" by "moving fast and breaking things"...

@Dave_Maynor that others clean up.