|Summary:||[Patch] Segmentation fault when accessing xlib backend from different endian systems|
|Product:||cairo||Reporter:||Wolfgang Meyer <wolfgang.meyer>|
|Component:||xlib backend||Assignee:||Chris Wilson <chris>|
|Status:||RESOLVED MOVED||QA Contact:||cairo-bugs mailing list <cairo-bugs>|
|i915 platform:||i915 features:|
|Bug Depends on:|
Proposed patch to the bug
Do not decrement from MAXINT to 1 in byteswap code if width or stride == 0
There is no point attempting to byteswap if surface->data == NULL
Description Wolfgang Meyer 2013-04-12 09:45:27 UTC
Created attachment 77856 [details] Proposed patch to the bug Accessing the cairo xlib backend via X11 forwarding on (big endian) HP-UX from a little endian system leads to a segmentation fault. The crash occurs in the _cairo_xlib_surface_add_glyph function. At line 1321 if c is zero an infinite loop causes the segmentation fault. The attached patch seems to prevent the crash.
Comment 1 Frederic Crozat 2014-07-08 10:35:27 UTC
I can confirm this patch is fixing similar crash on s390x when logging from a x86_64 client over ssh. Please commit to 1.12 and master branch.
Comment 2 Ryan Oliver 2014-09-18 04:36:35 UTC
Created attachment 106473 [details] [review] Do not decrement from MAXINT to 1 in byteswap code if width or stride == 0
Comment 3 Ryan Oliver 2014-09-18 04:38:43 UTC
Created attachment 106474 [details] [review] There is no point attempting to byteswap if surface->data == NULL
Comment 4 Ryan Oliver 2014-09-18 04:40:10 UTC
Issue will also affects the xcb backend. There are 2 problems here with the byteswap code 1) The above mentioned looping while decrementing from MAXINT if width or stride == 0 2) Dereferencing a null pointer if surface->data == NULL The latter causes the segfault on solaris-sparc <-> solaris-x86. Issue is triggered via the call to cairo_image_surface_create_for_data in src/cairo-ft-font.c (_render_glyph_outline, called from _cairo_ft_scaled_glyph_init) if the glyph requires a surface and width or height is 0. What you end up with is a surface with a NULL pointer as its data member. Whether this is sane or not for a surface, I don't know (XRenderAddGlyphs and xcb_render_add_glyphs must deal with being passed a NULL data pointer as would happens now for the non-byteswapped case...) Attaching 2 patches cairo-1.12.16-xlib_xcb_dont_decrement_from_zero_in_byteswap_code-1.patch (replaces attachment 77856 [details]) cairo-1.12.16-xlib_xcb_avoid_null_pointer_dereference_in_byteswap_code-1.patch
Comment 5 firstname.lastname@example.org 2015-11-04 18:56:46 UTC
I tried the most-recent proposed patch ( https://bugs.freedesktop.org/attachment.cgi?id=106473 and https://bugs.freedesktop.org/attachment.cgi?id=106474 ) In cairo 1.12.18: I can confirm that the patch is fixing a similar crash on Solaris 9 SPARC and Solaris 10 SPARC when logging in from a x86_64 client (Apple OS X) over ssh. But the patch introduces a new failure on Solaris 10 SPARC when logging in from a Solaris 10 SPARC client over ssh: a) Sometimes it works fine. b) Other times the appplication renders its windows and menus lacking all text and icons. The application crashes (leaving no core dump) within a few operations. c) Other times the application exits before anything is displayed. Output is: ssh -X -f foo.example.com wireshark Authenticated to foo.example.com ([192.168.1.10]:22). The program 'wireshark' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 144 error_code 2 request_code 131 minor_code 3) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Transferred: sent 15244, received 38328 bytes, in 1.8 seconds Bytes per second: sent 8400.2, received 21120.6 d) Other times are identical to (c), but before crashing, the app begins to display its splash screen. The crash happens before any text or icons are successfully displayed on the splash screen. Retries produce results among a, b, c, or d with no apparent pattern. So enough retries in launching the app will eventually hit (a) and be usable, working around the issue.
Comment 6 GitLab Migration User 2018-08-25 13:39:47 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/123.