Re: [PATCH 2/3] Documentation: security-bugs: explain what is and is not a security bug

[Demi Marie Obenour]

On 4/28/26 17:13, Greg KH wrote:
> On Mon, Apr 27, 2026 at 06:14:15PM +0200, Willy Tarreau wrote:
>> On Mon, Apr 27, 2026 at 09:35:04AM -0600, Greg KH wrote:
>>> On Mon, Apr 27, 2026 at 05:27:46PM +0200, Willy Tarreau wrote:
>>>> On Mon, Apr 27, 2026 at 07:48:23AM -0600, Greg KH wrote:
>>>>> On Sun, Apr 26, 2026 at 06:39:13PM +0200, Willy Tarreau wrote:
>>>>>> +In the Linux kernel's threat model, an issue is **not** a security bug, and
>>>>>> +should not be reported to the security list, when triggering it requires the
>>>>>> +reporter to first undermine the system they are attacking. This includes, but
>>>>>> +is not limited to, behavior that only manifests after the administrator has
>>>>>> +explicitly enabled it (loading a module, setting a sysctl, writing to a debugfs
>>>>>> +knob, or otherwise using an interface documented as privileged or unsafe); bugs
>>>>>> +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine the
>>>>>> +actor already fully controls, with no further privilege boundary being crossed;
>>>>>> +prediction of random numbers that only works in a totally silent environment
>>>>>> +(such as IP ID, TCP ports or sequence numbers that can only be guessed in a
>>>>>> +lab), issues that appear only in debug, lockdep, KASAN, fault-injection,
>>>>>> +CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended
>>>>>> +for production use; problems seen only under development simulators, emulators,
>>>>>> +or fuzzing harnesses that present hardware or input states which cannot occur
>>>>>> +on real systems; bugs that require modified or emulated hardware; missing
>>>>>> +hardening or defence-in-depth suggestions with no demonstrable exploit path
>>>>>> +(including local ASLR bypass); mounting file systems that would be fixed or
>>>>>> +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which should
>>>>>> +be reported to the relevant vendor. Functional and performance regressions,
>>>>>> +and disagreements with documented kernel policy (for example, "root can load
>>>>>> +modules"), are likewise ordinary bugs or feature requests rather than security
>>>>>> +issues, and should be reported via the usual channels.
>>>>>
>>>>> This is a great list to start with, but perhaps we should put it in list
>>>>> form so that it's easier to read?
>>>>
>>>> In fact that's what I tried first and it was super long with many short
>>>> lines, making it possibly worse. But maybe aggregating several short
>>>> entries on a line by similarities could work, I can give it a try.
>>>>
>>>>> Also, I can see this turning into a separate document eventually as
>>>>> different subsystems should have a chance to weigh in on what they
>>>>> consider the threat model to be
>>>>
>>>> My fear if we redirect to other files is that it won't be read again.
>>>> However, we could possibly suggest to always look for the subsystem's
>>>> specific rules in this subsytem's doc, leaving enough freedom to
>>>> maintainers to reject more things.
>>>
>>> AI tools are good at following links, so I wouldn't worry about that.
>>
>> Yes but let's not forget the minority of humble humans still sending
>> honest reports ;-)
>>
>>> We can point at other files, as this list is going to get long over
>>> time, which is a good thing.
>>
>> Sure. I'm just unsure where this could be enumerated, as it's likely
>> that there would be just one or two lines max per subsystem for the
>> majority of them. Or we could have a totally separate file, "threat
>> model", that goes into great lengths detailing all this with sections
>> per category or subsystem when they start to grow maybe, and refer only
>> to that one from security-bugs ?
>
> I think a separate file is good, I know I need to write up what the USB
> model is, and it's different from PCI, and different from other
> subsystems. All should probably be documented eventually.
>
>>>>> (like what the IB subsystem does which I
>>>>> don't think you listed above, or the USB subsystem.)
>>>>
>>>> Indeed I didn't list IB (I'm never sure about it, I seem to remember
>>>> we simply trust any peer, is that right?), nor did I make specific
>>>> mentions for USB which is implicitly covered by "hardware emulation
>>>> or modification".
>>>
>>> Ah, but USB does cover "some" modification of devices, so this is going
>>> to be something that is good to document over time, if for no other
>>> reason to keep these scanning tools in check from hallucinating crazy
>>> situations that are obviously not a valid thing we care about.
>>
>> OK but does this mean you still want to get these reports in the end ?
>
> I want a patch if a user cares about that threat-model (as Android does
> but no one else) as it's up to the user groups that want to change the
> default kernel's behavior like this to actually submit patches to do so.
FYI, I don't think this is limited to Android. Chrome OS definitely
cares about malicious USB devices, and the whole purpose of USBGuard is
to prevent a USB device from being able to compromise the system unless
authorized. I believe Qubes OS also cares, as it supports USB device
assignment to virtual machines. CCing qubes-devel for confirmation.

What should that patch look like? Could there be a way for these user
groups to be informed of vulnerabilities in the USB subsystem, so that
they can take responsibility for fixing them before they become public?

It does make sense for those who care about the security of a subsystem
to be responsible for vulnerabilities in that system, but right now
I'm not sure how one would offer to take up that responsibility.
--
Sincerely,
Demi Marie Obenour (she/her/hers)

[Demi Marie Obenour]

On 5/2/26 01:35, Willy Tarreau wrote:
> Hi Demi Marie,

>
> On Sat, May 02, 2026 at 01:20:10AM -0400, Demi Marie Obenour wrote:
>>>>> Ah, but USB does cover "some" modification of devices, so this is going
>>>>> to be something that is good to document over time, if for no other
>>>>> reason to keep these scanning tools in check from hallucinating crazy
>>>>> situations that are obviously not a valid thing we care about.
>>>>
>>>> OK but does this mean you still want to get these reports in the end ?
>>>
>>> I want a patch if a user cares about that threat-model (as Android does
>>> but no one else) as it's up to the user groups that want to change the
>>> default kernel's behavior like this to actually submit patches to do so.
>> FYI, I don't think this is limited to Android. Chrome OS definitely
>> cares about malicious USB devices, and the whole purpose of USBGuard is
>> to prevent a USB device from being able to compromise the system unless
>> authorized. I believe Qubes OS also cares, as it supports USB device
>> assignment to virtual machines. CCing qubes-devel for confirmation.
>>
>> What should that patch look like? Could there be a way for these user
>> groups to be informed of vulnerabilities in the USB subsystem, so that
>> they can take responsibility for fixing them before they become public?
>

> I've posted a proposal elsewhere in the same thread:
>
> https://lore.kernel.org/lkml/afSxSX8R...@1wt.eu/

I saw that, but it's still not quite clear what is meant here.
My understanding is that those concerned about malicious USB devices
are generally concerned about _arbitrary_ malicious USB devices.
The one thing a USB device shouldn't be able to spoof is the port
it is plugged into, and userspace tools like USBGuard can use that
information. But to do that, they have to trust that the device
can't harm the system if it isn't assigned to any drivers.

>> It does make sense for those who care about the security of a subsystem
>> to be responsible for vulnerabilities in that system, but right now
>> I'm not sure how one would offer to take up that responsibility.
>

> I think that at least some subsystems will want to add their own
> restrictions based on the bug reports they keep receiving, and I hope
> it can help distros figure where there's a gap between is promised to
> users and what the kernel promises, that needs to be filled by userland
> verification tools for example.
>
> Willy

I think there might be another category, which is were there is a
third party who is much more interested in the security of a subsystem
than its primary maintainers are. I suspect that Google is said
third party in multiple such cases, especially various USB drivers.
In particular, exploiting the kernel via USB is a common attack
technique used in the wild by tools like Cellebrite.

In these cases, I think it makes sense to funnel vulnerability
reports to the people who actually seriously care about fixing them.
For instance, problems in USB might be funneled to the Chrome OS and
Android security teams. They will get fixed much more quickly, and
upstream maintainers won't be flooded with reports that don't have
attached patches.

[Demi Marie Obenour]

On 5/2/26 02:07, Willy Tarreau wrote:

> The goal sought by that early document precisely is to draw the line
> between what is a regular bug and hwat is a kernel bug. The kernel
> currently doesn't consider problems posed by a crafted USB device as a
> security issue because the kernel trusts the hardware in runs on. Of
> course there can be valid reasons to disagree with this, but it's just
> the current situation and the purpose of the document is to clarify it
> so that bugs are reported to the right place and handled efficiently.

Fair. That does bring up the question of what those who want
to change that situation should do, and they definitely exist.
A documented path for them to follow (even if long and convoluted,
such as becoming co-maintainers of the subsystem) could be helpful.

I'd offer to help write something, but I suspect that this is
something that can only really be written by a member of the kernel
security team. Hence this request.

>>>> It does make sense for those who care about the security of a subsystem
>>>> to be responsible for vulnerabilities in that system, but right now
>>>> I'm not sure how one would offer to take up that responsibility.
>>>
>>> I think that at least some subsystems will want to add their own
>>> restrictions based on the bug reports they keep receiving, and I hope
>>> it can help distros figure where there's a gap between is promised to
>>> users and what the kernel promises, that needs to be filled by userland
>>> verification tools for example.
>>>
>>> Willy
>>
>> I think there might be another category, which is were there is a
>> third party who is much more interested in the security of a subsystem
>> than its primary maintainers are. I suspect that Google is said
>> third party in multiple such cases, especially various USB drivers.
>> In particular, exploiting the kernel via USB is a common attack
>> technique used in the wild by tools like Cellebrite.
>

> Possibly that such ones might appear there at some point. The best
> way for these might be to have such teams try to step up as
> co-maintainers for the parts they care about though.

Makes sense.

>> In these cases, I think it makes sense to funnel vulnerability
>> reports to the people who actually seriously care about fixing them.
>> For instance, problems in USB might be funneled to the Chrome OS and
>> Android security teams. They will get fixed much more quickly, and
>> upstream maintainers won't be flooded with reports that don't have
>> attached patches.
>

> Trust me, patches written behind closed doors rarely resist publication
> and discovery by the maintainer. And treating bugs as regular ones in
> fact tends to make them move faster than as security ones. No need to
> go back-and-forth asking for data that reporters hesitate to share, nor
> to have to first convince them that their bug needs to be fixed even
> though they were planning on speaking about them at a conference, etc.

That doesn't surprise me, actually.