How I Found a 20-Year-Old Linux Kernel Bug
robert.ocallahan.org
How I Found a 20-Year-Old Linux Kernel Bug
1–10 of 45 posts
Re: How I Found a 20-Year-Old Linux Kernel Bug
#2Re: How I Found a 20-Year-Old Linux Kernel Bug
#3Re: How I Found a 20-Year-Old Linux Kernel Bug
#4The bug was in from day 1.
Re: How I Found a 20-Year-Old Linux Kernel Bug
#5I 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.
proposed patch here:
https://bugzilla.kernel.org/attachment.cgi?id=256997&action=...
Re: How I Found a 20-Year-Old Linux Kernel Bug
#6It'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.
(disclamer: I'm one of the QuickFuzz [0] developers and I'm very interested in testing for this kind of bugs)
Re: How I Found a 20-Year-Old Linux Kernel Bug
#7Re: How I Found a 20-Year-Old Linux Kernel Bug
#8Segfaults are horrible, but bugs like these are even more so. Crawling, sneaking, living in your walls. Stealing precious CPU cycles and memory from millions of machines at once--petabytes and petaflops when you add it all up.
Worst yet, they don't make a peep until you shine the holy light of benchmarks, code reviews, automated testing, or the (un)lucky corner case on them.
At least segfaults let you know something's definitely wrong. These bugs? Now that's insidious.
Re: How I Found a 20-Year-Old Linux Kernel Bug
#9did this guy get a bug bounty?