How I Found a 20-Year-Old Linux Kernel Bug • Hacker News Board

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

#31

Post by frozenport » Thu, Jun 15, 2017, 9:14 AM UTC

wyc wrote: post #8

Great work! Segfaults 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 kno…

A segfault is how the memory management gods show mercy

https://www.reddit.com/r/programmingcirclejerk/comments/62d1...

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

#32

Post by hashhar » Thu, Jun 15, 2017, 10:16 AM UTC

glangdale wrote: post #21

The 'rr' project gets a side mention, but if you're into debuggers, it's really worth a look - a very practical "record and replay" debugger that allows you to move around in time in a debug session. http://rr-project.org/

rr is indispensable to me specially as I started hacking around on Firefox and other C++ codebases (lack of interactive debuggers).

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

#33

Post by rullelito » Thu, Jun 15, 2017, 10:38 AM UTC

I've never done any kernel/low level stuff, so sorry for a probably stupid question. Will this bug only happen when there is less than 40 bytes but more than 31 bytes available? (i.e. less than 32 bytes will fail anyway)

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

#34

Post by nathan_f77 » Thu, Jun 15, 2017, 10:43 AM UTC

Terrifying to think that tiny, subtle bugs like this could exist in pacemakers and planes. Especially if something like this only happens once every decade or so:

> I guess once in a while it would fail if your allocator happens to land one at the end of a page.

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

#35

Post by jwilk » Thu, Jun 15, 2017, 11:14 AM UTC

bonzini wrote: post #12

_e wrote: post #7

did this guy get a bug bounty?

It's not a security-sensitive issue.

FWIW, not all bug bounty programs are about security.

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

#36

Post by [deleted] » Thu, Jun 15, 2017, 11:15 AM UTC

dsego wrote: post #10

given enough eyeballs, all bugs are shallow

[deleted]

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

#37

Post by WhiteSource1 » Thu, Jun 15, 2017, 12:48 PM UTC

And clearly no one noticed it in 20 years....

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

#38

Post by aneutron » Thu, Jun 15, 2017, 1:12 PM UTC

wextsucks wrote: post #29

Title should have been "How i found a bug in some deprecated 802.11g-era API that is disabled by default" I always wonder why the kernel does not just warn when this API is used or yank it. Any software stuck with this API can barely know about 802.11n and is probably wondering what is 802.11ac or 802.11ax. Only some old or broken device drivers require this API. Linux distros should just stop enabling this API.

I actually use a 802.11g because work. So no thanks.

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

#39

Post by alkonaut » Thu, Jun 15, 2017, 1:37 PM UTC

hashhar wrote: post #32

glangdale wrote: post #21

The 'rr' project gets a side mention, but if you're into debuggers, it's really worth a look - a very practical "record and replay" debugger that allows you to move around in time in a debug session. http://rr-project.org/

rr is indispensable to me specially as I started hacking around on Firefox and other C++ codebases (lack of interactive debuggers).

Why are there no interactive debuggers if you develop firefox?

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

#40

Post by alkonaut » Thu, Jun 15, 2017, 1:39 PM UTC

lomnakkus wrote: post #30

ethbro wrote: post #26

Earlier quoted context omitted.

I think the counter point of this is being kind when people report bugs that aren't bugs. If users encounter a weird result, report it, and have someone call them an idiot because they misunderstood a nuance of the system... they're probably not going to take the time to report next time around. (And I get it, there's that common issue that people consistently misunderstand and you continually get reports about. But…

I think your parenthetical probably explains the dismissive attitude many upstreams have, but I would argue that if so many people are (consistently) misunderstanding your software then there's probably a UI/UX/education problem that needs fixin'... (Not saying it's easy , but it's a sign...)

Someone said, somewhere: User files bug that isn't a bug:

bad/rookie dev: omg dumb user

good dev: closes bug issue, files new issue to fix docs.