Stable kernel 2.6.25.10

> Yes, I do understand this stuff.

so what made you say that a refcount overflow or a null function pointer dereference are not
security issues worthy of disclosure? if even you are aware of these exploitable bug classes,
then certainly we can expect kernel devs dealing with security issues to know better as well.

> But I've also fixed bugs that turned out (later!) to be security vulnerabilities.

i wasn't talking about bugs whose security impact was realized only later. in this case both
bugs are representative of well known exploitable bug classes, and at least one of them was
discussed on vendor-sec, yet no CVE or any sort of disclosure is in sight.

> Sure, "possible buffer overflow" (and other classes) is a big warning
> sign, but not a guarantee that it is exploitable.

in which case the prudent approach is to err on the side of safety and declare it as a
potentially exploitable bug, not covering it up for good.

> I much prefer kernel (and other) developers fixing bugs than running
> around finding out if bugs can be exploited.

you're welcome to read the previous threads as this has been discussed already: noone expects
kernel devs to do this kind of evaluation. what people do expect from them is following
Documentation/SecurityBugs and disclose security impact information when they're aware of it.

besides, they're well aware of severaly exploitable bug classes, they don't have to find out
anything to mention that detail in the commit.

> And a bug that can't be exploited today might become exploitable in the
> future due to changes elsewhere.

are you suggesting that kernel devs leave bugs unfixed in the hope they become actually
exploitable in the future? else the above doesn't make any sense, if a bug is known and fixed,
how can it become exploitable in the future?

> Finding out if a bug is exploitable is a different skill than development.

agreed and it's not the subject of this discussion.