On Tue, Jul 03, 2012 at 11:32:11AM +0200, Etienne Millon wrote: > > My first idea was to check if strlen(format->matrix) is within > > reasonable boundaries, before using it to allocate memory. > > I think that it's perfectly reasonable for libao to segfault in such a > case. That's the same when one passes an invalid pointer to strlen or > such a function with a "strong" invariant : the caller is responsible.
If there was actually a way to catch it and do something, I'd have no hesitation with making a patch and sending it upstream. There just really isn't anything we can do if it wasn't already checked by the caller here. We check for it being NULL (and use the default matrix if so), and the _sanitize_matrix() function, well, sanitizes the matrix string if you do pass one ... which pretty much covers all the bases we can cover from in libao itself. Sure, you could pass it a huge string and make it allocate "a lot" of memory ... but no more than you yourself already allocated to ensure the string had no NUL in it, and there's no reason for apps to let untrusted data supply that string, so ... About the only obvious thing that might be fixed in _sanitize_matrix is it isn't checking calloc for a NULL return, but this should always be a tiny string, so if that fails, you're already badly doomed anyway - and exploding on a 'harmless' NULL dereference there would hardly be robbing you of a glowing future (it's not in any way otherwise exploitable). > > The only real mystery remaining is why zsnes hasn't been reported to > > die like this before now ... > > The mysteries of stack layout... Maybe the previous stack frame > held zeroes at the correct offset on i386. Yeah, it being zero by luck, or just somehow not actually tested down this codepath are really the only explanations I have too. But it wouldn't be the first "how did this ever work before" bug I've seen this year either :) I'm glad we've got this side of it at least sorted out now though. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org