Bug 65252 - XvQueryPortAttributes (libXv) does not guarantee nil-terminated names and can return uninitialized memory
Summary: XvQueryPortAttributes (libXv) does not guarantee nil-terminated names and can...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/other (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Alan Coopersmith
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-02 02:09 UTC by Daphne Pfister
Modified: 2013-06-07 05:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch to fix (1.26 KB, patch)
2013-06-02 02:44 UTC, Daphne Pfister
no flags Details | Splinter Review

Description Daphne Pfister 2013-06-02 02:09:07 UTC
XvQueryPortAttributes has two issues with regards to returning names for attributes that could possibly reveal information to a compromised server.

1) It does not guarantee that the name strings are nil terminated, instead trusting the names sent by the server.
2) If the last attribute(s) have sizes that would overflow the available text string space left, the name pointers will point to uninitialized memory with what ever contents was in the memory as returned by Xmalloc.

Because these attribute names need to be converted to atoms before being used by other API calls in libXv, it is possible that the uninitialized memory or memory pass the end of the unterminated string could be exposed to the server.

This is true as of libXv 1.0.8
Comment 1 Daphne Pfister 2013-06-02 02:44:59 UTC
Created attachment 80145 [details] [review]
Patch to fix

This patch attempts to fix this bug by ensuring that there is at least one nil byte at the end of all the name strings. This should prevent reading past the end of the allocation as well as exposing uninitialized memory.

The (INT_MAX/2) - 1 change isn't necessary because of rounding adding 1 will not overflow, but seems pointless to require the mental arithmetic every time the code was read.  ( Proof: 2*(INT_MAX/2) == INT_MAX - 1 assuming integer math and that INT_MAX is always odd. )
Comment 2 Alan Coopersmith 2013-06-07 05:14:21 UTC
Fix pushed to git master:
To ssh://git.freedesktop.org/git/xorg/lib/libXv
   179ed25..22cc0c8  master -> master

http://cgit.freedesktop.org/xorg/lib/libXv/commit/?id=22cc0c897a28a41d49fe68277bb3c002f54bbb48

Thanks for finding & fixing this!


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.