[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:
