After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625692 - Pixbuf get_pixels() past end of malloced block
Pixbuf get_pixels() past end of malloced block
Status: RESOLVED FIXED
Product: gnome-perl
Classification: Bindings
Component: Gtk2
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk2-perl-bugs
gtk2-perl-bugs
Depends on:
Blocks:
 
 
Reported: 2010-07-30 22:05 UTC by Kevin Ryde
Modified: 2010-11-23 21:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
failing program, when run under electric fence (281 bytes, text/x-perl)
2010-07-30 22:05 UTC, Kevin Ryde
  Details
patch and test case (3.63 KB, patch)
2010-07-30 22:07 UTC, Kevin Ryde
committed Details | Review

Description Kevin Ryde 2010-07-30 22:05:57 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.
Comment 1 Kevin Ryde 2010-07-30 22:07:12 UTC
Created attachment 166861 [details] [review]
patch and test case
Comment 2 Emmanuele Bassi (:ebassi) 2010-07-31 10:50:13 UTC
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.
Comment 3 Torsten Schoenfeld 2010-11-23 21:08:30 UTC
Looks good, committed.  Thanks.