[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Fun with NULL pointers, part 2

Fun with NULL pointers, part 2

Posted Jul 22, 2009 8:47 UTC (Wed) by msmeissn (subscriber, #13641)
In reply to: Fun with NULL pointers, part 2 by christian.convey
Parent article: Fun with NULL pointers, part 2

Well, Coverity scans the kernel.

They issued a press release that they found the issue (REVERSE_INULL I
would guess).

Just someone needs to read and investigate all the reports, and
its quite an amount and not so funny work.

Ciao, Marcus


to post comments

Fun with NULL pointers, part 2

Posted Jul 22, 2009 12:13 UTC (Wed) by nick.lowe (guest, #54609) [Link] (4 responses)

Fun with NULL pointers, part 2

Posted Jul 22, 2009 12:51 UTC (Wed) by spender (guest, #23067) [Link] (3 responses)

Now that the blog was posted, I can mention that the tun.c bug was found by Coverity months ago and reported, but it went unfixed.

Couple that with the information from this study:
http://www.usenix.org/events/usenix09/tech/full_papers/gu...

that 40% of the issues reported by the static checkers aren't being triaged.

-Brad

Fun with NULL pointers, part 2

Posted Jul 22, 2009 20:52 UTC (Wed) by hmh (subscriber, #3838) [Link] (2 responses)

Is the information that the checker produces actually getting to the developers that can do something about it?

That seems to be a valid question...

Fun with NULL pointers, part 2

Posted Jul 22, 2009 21:04 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

this is actually a very interesting presentation. videos are available at
http://www.usenix.org/events/usenix09/tech/ (I believe they are available to everyone, not just usenix members, please let me know if that is not the case)

there are a number of trends (not very surprising in retrospect)

if you have a false positive, the chances of anyone paying attention to further reports in that section of the code drop drasticly.

if you have a maintainer who looks at one report, the chances of them dealing with all of them in that area go up significantly

if a fix is produced as a result of a report, the chances of all the reports for a given area being looked at and fixed go up drasticly

if there is not an active maintainer of that section of code the chances of the reports being looked at go down drasticly.

a large percentage of real bugs and vunerabilities have had reports on that section of the code (note that this is _not_ the same thing as saying that a large percentage of reports have been found to cause real bugs and vunerabilities)

there is a significant push from kernel developers to avoid rushing to clean up the code to silence the warnings, there is a large enough correlation between these reports and more significant bugs that many of them want the entire section where reports are found to be examined, there is a significant chance that there is a more significant and subtle bug lurking in that area.

Fun with NULL pointers, part 2

Posted Jul 23, 2009 2:36 UTC (Thu) by spender (guest, #23067) [Link]

The videos require being a USENIX member.

-Brad


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds