Bug 63461 - [Patch] Segmentation fault when accessing xlib backend from different endian systems
Summary: [Patch] Segmentation fault when accessing xlib backend from different endian ...
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: xlib backend (show other bugs)
Version: 1.12.14
Hardware: IA64 (Itanium) HP-UX
: medium major
Assignee: Chris Wilson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: cairo-1.14
  Show dependency treegraph
 
Reported: 2013-04-12 09:45 UTC by Wolfgang Meyer
Modified: 2018-08-25 13:39 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Proposed patch to the bug (373 bytes, text/plain)
2013-04-12 09:45 UTC, Wolfgang Meyer
Details
Do not decrement from MAXINT to 1 in byteswap code if width or stride == 0 (1.94 KB, patch)
2014-09-18 04:36 UTC, Ryan Oliver
Details | Splinter Review
There is no point attempting to byteswap if surface->data == NULL (3.50 KB, patch)
2014-09-18 04:38 UTC, Ryan Oliver
Details | Splinter Review

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 irwin@princeton.edu 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.