You're obviously saying this as someone who has never had to assess whether a bug in your code could have a security impact or not. I'm regularly having to do that in my code, which is far less complex than the kernel and it's already a nightmare. "what can be the impact of that flag that was not cleared in that struct between two calls, could anything go wrong with it left on?". Sometimes it even depends on build options.

When Linus used to say "a bug is a bug", it really means it: a bug is first and foremost a bug. And sometimes some people are smarter than others and manage to assemble several of them together and turn a sequence of tiny individual and unrelated bugs into an exploitable one. I'm sorry but it really requires skills that are far beyond the vast majority of developers'.

I remember once a security researcher reported a bug in my code, something like a trailing zero being written one byte past the end of an area, but in an unaligned struct so theoretically it wouldn't have had an impact. But being an off-by-one, I asked him whether he thought it could be exploited. He found the challenge tempting and ended up two weeks later explaining who he finally managed to combine that with something else to inject a pointer that ends with a zero on little endian 32-bit archs, and which depending where the program was loaded in memory, 255/256 times would do nothing but freeze your connection due to the bug, and 1/256 times manage to trigger a deref that allowed him to inject the payload that preceeded the pointer. He didn't even have a reliable reproducer, just studied the possibility. This is what assessing a bug's impact corresponds to.

Hence when you don't know, in doubt, it may have security impacts.

Now regarding asking the kernel devs, even the top-level subsystem maintainers who are regularly asked to validate some reports that land on the security list can sometimes scratch their heads for quite a moment before figuring whether or not there really is something, after someone reported it.

The point is that it's never written on the bug that it has a security impact, and in general if you say no in less than one week of studying, you're just wrong.

Well, if you investigate and tell them, then they'll know what to tell you!

Kernel devs are NOT omniscient. Kernel devs do NOT know everything. Kernel devs are too busy *fixing* the bug to have time to waste investigating what security impact it may (or may not) have.

Please do NOT assume that kernel devs are cleverer than you. Please do NOT assume that kernel devs know more than you. (Unless of course, you yourself are happy to assume you are an idiot :-)

At the end of the day, if you're not prepared to do the work, don't assume someone else will. They won't. And that INCLUDES investigating the security implications of fixing a bug. As a developer myself, I DON'T CARE what the consequences of a bug are - unless, of course, it's forced upon me by something going wrong. All I care about is if there's a logic error, I want it fixed.

I go on about this story, but I took over a code base. It was dodgy, unreliable, and we didn't know what was wrong. I jacked the warning level to max, fixed all the warnings, and the problems went away. Were those bugs security bugs? Were those bugs serious bugs? Were those bugs trivial bugs? Were those bugs in code that was never reached? I didn't know, I didn't care, I'll never find out.

Why would the kernel devs know or care?

Cheers,
Wol

Ok, my view as a by-stander was that this is exactly what many people are asking for. Always accompanied with vague insinuations that there is some conspiracy to hide known security issues from the public.

> We just want kernel devs to tell us whatever they already know.

"Kernel devs" are not a well defined group. Of the ~12k fixes in 6.1 in a year, the people who might have thought about the security implications of each fix might be the author and perhaps a handful of reviewers. Figuring out if some fix might be security related is somewhat of an art, and something most people just aren't very good at.

Never attribute to malice that which can be adequately explained by stupidity, incompetence or laziness.

On a higher level, it's not clear to me the point of issuing lots of CVEs for things that you don't actually know are a problem. You could create a CVE for every invalid memory reference, that might make several hundred extra CVEs, but what's the point here? The only way to get fixes is to upgrade, at which point it makes no difference if there was one CVE issued or 500. Every single released version of the Linux kernel has vulnerabilities, so what exactly is the purpose of assigning lots of CVEs in the first place? It's good for pretty graphs, I'm sure.

(Some of this is from irritation from a constant stream of "security alerts" which amount to "package X has a problem if you use it in a way that's clearly stupid or a situation which is very rare". There's a cost to assigning a CVE and at some point that cost outweighs the benefits. It's would be nice if there was a numbering scheme for security things things that should be highlighted in a changelog but are not likely to affect a significant number of people.)

Posted Feb 14, 2024 2:04 UTC (Wed) by pizza (subscriber, #46) [Link]