Bug 857262

Created attachment 612665 [details]
Test application

Description of problem:

A customer reported crashes in their application. We determined that this was due to an overflow in libxcb. The bug is fixed upstream, and we were able to provide the customer with a patched libxcb to resolve their issue, but RHEL 6.3's libxcb still has the bug.

Version-Release number of selected component (if applicable):

1.5

How reproducible:

Set an X display's request number to 2^32 - 1, then increment it by one. A sample application is attached.

Steps to Reproduce:
1. Build the attached test_force_bad.c application with `gcc -lX11 test_force_bad.c -o test_force_bad`
2. Run the built application
  
Actual results:

The app triggers an XIO error:

$ ./test_force_bad  
request = 0x100000000 (4294967296), last_request_read = 0xffffffff (4294967295) 
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" 
      after 4294967297 requests (4294967295 known processed) with 0 events remaining. 

Expected results:

The XIO error should not occur. (Note: if the error doesn't occur, the app will hang forever waiting for packets that will never arrive. This is because the request number was forced, and is expected behavior for this application.)

Additional info:

We are aware that Red Hat plans to update libxcb, along with other components of the graphics stack, in RHEL 6.4. This bug is filed to ensure that libxcb in RHEL 6.4 does not have this problem. If it's possible to backport the fix to earlier versions of RHEL 6, that would be nice.

The upstream fixes do not apply cleanly against the version of libxcb in RHEL 6.3, so we've also attached a tarball with backported patches that resolved the issue for the customer on RHEL 6.2.

This is fixed upstream with the following commits:

commit ed37b087519ecb9e74412e4df8f8a217ab6d12a9 
Author: Jamey Sharp <jamey > 
Date:   Sat Oct 9 17:13:45 2010 -0700 
 
    xcb_in: Use 64-bit sequence numbers internally everywhere. 
     
    Widen sequence numbers on entry to those public APIs that still take 
    32-bit sequence numbers. 
     
    Signed-off-by: Jamey Sharp <jamey > 
 
commit ee1bc1d28a1bda0526db90139edc1304d2ef3d7c 
Author: Jamey Sharp <jamey > 
Date:   Sat Oct 9 04:08:18 2010 -0700 
 
    xcb_send_request: Send all requests using a common internal send_request. 
     
    This simplifies the critical section of xcb_send_request and fixes a 
    couple of subtle bugs: 
     
   - It's possible for xcb_send_request to need to issue two sync requests 
      before it can issue the real request. Previously, we counted sequence 
      numbers as if both were issued, but only one went out on the wire. 
     
   - The test for whether to sync at 32-bit sequence number wrap has been 
      incorrect since we switched to 64-bit sequence numbers internally. 
     
    This change means that if the output queue was already full and the 
    current request is bigger than the output queue, XCB will do one more 
    write syscall than it did before. But syncs are rare and small requests 
    are the norm, so this shouldn't be a measurable difference. 
     
    Signed-off-by: Jamey Sharp <jamey >