#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 ttcoder): Looks like a buffer re-use optimization done wrong.. (Donald Knuth would have something to say about that, something like "premature optimization is the root(fs) of all evil" 8-).. There's a bit of that in Haiku.. But we still love you guys :-b Anyway big kudos to you Michael; went on a hunt for other tickets/symptoms beside the 3 closed, that you might get credited with fixing too. 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 ?) Or maybe the slab debugger mentionned by bonefish in #comment:8 is the one to use in that kind of situation ? 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). 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. -- Ticket URL: <https://dev.haiku-os.org/ticket/10259#comment:13> Haiku <https://dev.haiku-os.org> Haiku - the operating system.