GNOME Bugzilla – Bug 625692
Pixbuf get_pixels() past end of malloced block
Last modified: 2010-11-23 21:08:34 UTC
Created attachment 166860 [details] failing program, when run under electric fence $pixbuf->get_pixels() reads bytes past the end of the pixbuf data. It treats the data as if the last row was a full rowstride, but the pixbuf manual says the last doesn't have that padding, only width*n_channels bytes. Pixbufs created with $pixbuf->copy have a malloced block with the last row unpadded. Running foo.pl below under electric fence gets a segv from XS_Gtk2__Gdk__Pixbuf_get_pixels() going past the end of the block in the $p2 pixbuf. For most pixbufs the rowstride is just a multiple of 4, and malloced blocks are rounded up to a multiple of 4 anyway. But if you have a bigger rowstride like the 256 in foo.pl then the problem shows up. Perhaps the change below to use actual row width for the last row. I wonder if anyone has depended on the padded size in the return. You'd hope not. I think the shorter size is still right for new_from_data(), and the final padding is garbage.
Created attachment 166861 [details] [review] patch and test case
Review of attachment 166861 [details] [review]: the patch looks obviously correct ::: xs/GdkPixbuf.xs @@ +332,3 @@ + simply n_channels many bytes-per-pixel, but the calculation + anticipates bits not a multiple of 8. */ + different colorspaces and different BPP sizes will never happen - and if it ever did, gdk-pixbuf's API would probably be bumped.
Looks good, committed. Thanks.