@gregkh could it be LLM's discovering the 'security vulnerability' and not understanding the threat model? Not sure why there would be 5 at the same time though
> Is there some big usb-over-ip installation somewhere
Probably not that security sensitive because on the same machine but WSL2
@gregkh there is a small installation of two computers at my home that works well since this was out-of-tree
@gregkh a pattern I have seen recently is new people on kernel reporting bugs on random subsystems. I am pretty sure they just feed the code to a LLM and send whatever it found.
E.g yesterday I got a review on a patch I sent a year ago on protocol that is pretty uncommon. After talking to the reviewer, it is clearly an AI. It is by the way, the same person that sent a 22 patches series for rtl8723bs that you needed to review :/
@gregkh @aho Yeah, would not put too much trust into self-reporting LLM use, given our experiences in #curl.
I see duplicate reports more often nowadays and I suspect people use just the same review tools.
So we just need one tool add something new to their training/context/agent thing and several humans will claim a report.
Not the greatest use of everyone‘s time.
@gregkh My guess is someone made a novel prompt that made their LLM focus specifically on the USBIP protocol. It found and reported a minor issue. Now all other LLMs have the original report in their model, so they naturally focus on the USBIP protocol when presented with generic prompts, such as "find a vuln in the kernel", and now that effect is snowballing.
@gregkh I am sure there are also humans in the loop, but the LLMs are driving the snowball effect.
Jeah :)
If you would want to infiltrate the kernel your first step would not be to provide a patch with a backdoor.
You would do a bug-report, let it linger some time, discuss a bit and finally provide a patch. Maybe split the backdoor over multiple patches.
@gregkh @m_berberich 1) Specify a new security bug,
2) Let an LLM code a backdoor according to the spec,
3) Profit!