Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I Found a 20-Year-Old Linux Kernel Bug

robert.ocallahan.org

Post reply on HN
Print view View original

11–20 of 45 posts

Re: How I Found a 20-Year-Old Linux Kernel Bug

#11

Post by carussell »

dom0 wrote: post #4

Linux ~4.7 or so fixed a bug in fadvise, specifically FADV_DONTNEED, that incorrectly rounded page boundaries to the effect of making some calls less effective. Found and fixed by a developer who wondered why his page cache was filling up, even though the backup software he used made use of DONTNEED :) The bug was in from day 1.

The thing I wonder about in instances like this is how many people ran into the problem and thought, "Huh, there must be some quirky rationale here, and it's just an idiosyncrasy I'll have to deal with", or, "Huh, that's definitely wrong... oh well".

Re: How I Found a 20-Year-Old Linux Kernel Bug

#14

Post by aleksi »

hultner wrote: post #2

It's always nice to see fixes of problems found with improved testing. It would be nice to see something like Haskells QuickCheck rigorously applied on the majority of the kernel functions/interfaces.

Something like https://github.com/google/syzkaller?

Re: How I Found a 20-Year-Old Linux Kernel Bug

#17

Post by dom0 »

dom0 wrote: post #4

Linux ~4.7 or so fixed a bug in fadvise, specifically FADV_DONTNEED, that incorrectly rounded page boundaries to the effect of making some calls less effective. Found and fixed by a developer who wondered why his page cache was filling up, even though the backup software he used made use of DONTNEED :) The bug was in from day 1.

Ah, I almost got it right. It discarded too much, thus reducing throughput - even more subtle.

https://github.com/torvalds/linux/commit/18aba41cbfbcd138e9f...

Re: How I Found a 20-Year-Old Linux Kernel Bug

#18

Post by geofft »

dsego wrote: post #10

given enough eyeballs, all bugs are shallow

Sure, but it's not at all clear eyeballs are the most efficient way to find bugs. They seem remarkably inefficient compared to computers, which have generally shown themselves to be good at monotonous mechanical work that requires good attention to detail and no creativity.

In particular it seems to me like this could have been fixed with a better, machine-readable description of the types/structures for each ioctl, plus a static analysis tool that makes sure that the kernel does a copy_from_user on exactly what the documented input types are and no more or less. There is already a halfhearted attempt to encode type information in ioctls (the _IOR, _IOW, etc. macros), so I think this is doable. I'm not sure how much work is required to trace copy_from/to_user statically, but it certainly seems like it would be far less work than 20 years of people using these syscalls.

As another example, I think "given enough eyeballs, all bugs are shallow" would be a poor reason to eschew writing tests for your code.

Re: How I Found a 20-Year-Old Linux Kernel Bug

#20

Post by jjnoakes »

benmmurphy wrote: post #5
metalliqaz wrote: post #3

I have not ready anything about this bug, other than the very short description in the linked blog, however this seems like a bug that would have been flagged by a static analysis tool. I know they've been used on the kernel (e.g. Coverity) Very surprised it survived until now.

the syscall function takes a void* parameter then does a copy from user space into the kernel using the wrong target type/sizeof. i think it works because the incorrect type was a superset of the correct type. i don't think any static analyser could catch this. proposed patch here: https://bugzilla.kernel.org/attachment.cgi?id=256997&action=...

A static analyzer with sufficient inter-procedural analysis (i.e. across the user/kernel boundary) could certainly see the type of the allocated structure in userspace, and flag the kernel read of a larger type.
Post reply on HN