Ext4 data corruption in stable kernels

Posted Dec 18, 2023 11:38 UTC (Mon) by farnz (subscriber, #17727)
In reply to: Ext4 data corruption in stable kernels by jschrod
Parent article: Ext4 data corruption in stable kernels

I would marginally disagree; it is possible for a bug to not be a security bug. The difficulty is distinguishing bugs with no security relevance from those with security relevance, given that the kernel's overall threat model is very broad.

For example, a bug where the kernel sometimes clears the LSB of the blue channel of 16 bpc RGB colour on a DisplayPort link is almost certainly completely irrelevant; at the sorts of brightnesses monitors can do today, the difference between 16 bits each R and G and 15 bits of B, and 16 bits each R, G, B is below human perception.

But the challenge is that from my perspective, a bug in the kernel driver for a 100G Ethernet chip that connects via PCIe is completely irrelevant - I have no systems with that sort of hardware, nor is there a way for an attacker to add that hardware without my knowledge. Similarly, a bug in iSCSI that can only be tickled once iSCSI is in use is not security-relevant to me, since I have no iSCSI set up, so to tickle the bug, the attacker needs remote code execution already. From the perspective of a company running big servers that access bulk storage over iSCSI using 100G Ethernet, however, both of those bugs can be security bugs.

Should those bugs be "security" bugs, since if you happen to have the problematic setup, they're relevant? Or should they not be security bugs since most people don't have either 100G Ethernet or iSCSI setups?