[haiku-bugs] Re: [Haiku] #10259: CDDA-related KDL: ASCII string corrupts kernel structures

  • From: "mmlr" <trac@xxxxxxxxxxxx>
  • Date: Sat, 28 Mar 2015 23:54:35 -0000

#10259: CDDA-related KDL: ASCII string corrupts kernel structures
   Reporter:  ttcoder            |      Owner:  axeld
       Type:  bug                |     Status:  closed
   Priority:  normal             |  Milestone:  R1
  Component:  File Systems/cdda  |    Version:  R1/Development
 Resolution:  fixed              |   Keywords:
 Blocked By:                     |   Blocking:
Has a Patch:  0                  |   Platform:  All

Comment (by mmlr):

 Replying to [comment:13 ttcoder]:
 > I'm guessing the kernel "guarded heap" could have helped find this out-
 of-bounds write.. But as pulkomandy noted in 11718 it's impossible to run
 Haiku with it these days, not even with 8 GB RAM in Haiku x64. Maybe that
 guarded heap could be modified to allow guarding only one part of the OS
 at a time (probably not easy: malloc looks like malloc looks like malloc,
 no matter which kernel add-on calls it eh ?)

 The guarded heap did find this one, it's exactly what I wrote it for. It
 simply is a false assertion that a current Haiku can't be booted fully
 using it. Due to the waste in address space it most certainly isn't
 possible with a 32 bit version. With 64 bit only the amount of actually
 available pages is the limit. With the help of virtualization this limit
 doesn't really exist either, as the guest memory can be paged out and the
 limit becomes bound only by the size of your swap file.

 The much more difficult part about this particular bug was that qemu (and
 hence kvm) do not support audio CDs (or any kind of multi track for that
 matter) and therefore can't be used unmodified to reproduce the issue.
 That's why I had to resurrect the "-cdtoc" patch from the QEMU BeOS port
 from 10 years ago and make it emulate audio CDs instead.

 > Also interesting that Coverity did not tag that faulty strcpy, it's
 probably beyond it's heuristics' powers.. (but I'm biased against static
 analysis tools anyway).

 That is indeed curious. I would have expected it to find such a case.

 > Next time something like that occurs I ''have'' to think of going for
 broke and make the string suspected of a buffer overrun even ''bigger'':
 in this ticket's case, renaming the CD to a 250 bytes long name (instead
 of the puny 30 bytes or so of a typical cdda) would have likely crashed
 much faster and much more reliably, making it much easier to fix.

 Actually making it crash faster does not necessarily help you if the
 crashes are in random places due to more random corruption. This way you
 most often get innocent victims to crash, not the code that actually does
 the corruption (unless it happens to corrupt across an unallocated page
 boundary, which a large enough buffer might accomplish more easily
 indeed). Ultimately to find the place where the corruption happens you
 need the right tools, for example compiler/virtualizer assisted or
 hardware based memory guarding.

Ticket URL: <https://dev.haiku-os.org/ticket/10259#comment:14>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: