[Pkg-gmagick-im-team] Bug#619134: Bug#619134: /usr/bin/display: Bus Error on EIO

[Meelis Roos]

> >> > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)= 0x7feea7df3000
> >> > read(4, 0x7feea7df3000, 2048)           = -1 EIO (Input/output error)
> >> > lseek(4, 0, SEEK_SET)                   = 0
> >> > mmap(NULL, 8206, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7feea7df0000
> >> > close(4)                                = 0
> >> > munmap(0x7feea7df3000, 4096)            = 0
> >> > --- SIGBUS (Bus error) @ 0 (0) ---
> >> > +++ killed by SIGBUS +++
> >>
> >> SIGBUS after mumap an EIO file is not a imagemagick problem.
> >>
> >> see http://linux.die.net/man/2/mmap and also
> >> http://mail.gnome.org/archives/mc-devel/2001-September/msg00104.html
> >
> > Umm, yes, of course this is documented behaviour of mmap. But accessing
> > the mmaped region after close and munmap is where I see the bug here.
> > Use-after-free of sort. Am I wrong with this?
> 
> No it is not. Close release the file handle,  mumap release the memory handle.
> 
> try to open a file, mmap close it, and read mmap area you will see
> that you could still write to it.

Yes, you can stil read & write it while it is mmaped. But after munmap 
you can't:

The munmap() system call deletes the mappings for the specified address 
range, and causes further references to addresses within the range to 
generate invalid memory references.

mmap returns 0x7feea7df3000 and so 4096 bytes are mapped there. Fine. 
Later, munmap unmaps 4096 bytes from the same 0x7feea7df3000 address, so 
seems that everything it mmaped was unmapped...

I had a look trying to see at which location the SIGBUS came.

#0  memcpy () at ../sysdeps/x86_64/memcpy.S:267
#1  0x00007ffff79c4506 in ReadBlob (image=0x64b500, length=<value optimized out>, 
    data=0x7fffffff1970 "") at magick/blob.c:2724
#2  0x00007ffff7a77e21 in SetImageInfo (image_info=0x62b100, frames=<value optimized out>, 
    exception=0x605c00) at magick/image.c:3316
#3  0x00007ffff79f3ded in ReadImage (image_info=0x60a500, exception=0x605c00) at magick/constitute.c:445
#4  0x00007ffff76c4e64 in DisplayImageCommand (image_info=0x60a500, argc=2, argv=0x6023c0, 
    wand_unused_metadata=<value optimized out>, exception=<value optimized out>) at wand/display.c:513
#5  0x00007ffff773b06b in MagickCommandGenesis (image_info=0x606300, 
    command=0x400838 <DisplayImageCommand at plt>, argc=2, argv=0x7fffffffe1b8, 
    metadata=<value optimized out>, exception=0x605c00) at wand/mogrify.c:163
#6  0x00000000004009f5 in main (argc=2, argv=0x7fffffffe1b8) at utilities/display.c:104

Poking around some, it seems that the file is still mapped in 
/proc/PID/maps and image->blob->data points to the mmaped address. So 
it's not use after free, even when it looked like that from plain 
strace - I stand corrected.

So it's just that kernel notifies read errors from mmaped areas by 
SIGBUS and SIGBUS is documented as a possible way of accessing mmaped 
memory. It just looks like a missing signal handler in ImageMagick - it 
uses mmap and thus expects SIGSEGV but fails to catch it.

Looks more like an upstream design decision to ignore errors rather than 
possible quick debian-specific fix. Thus the severity 'minor' - but I 
still see it as a bug in ImageMagick, not in kernel.

-- 
Meelis Roos (mroos at linux.ee)