Bug 1459 - Stack overflow in libX11
Summary: Stack overflow in libX11
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Mike Harris
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-24 04:23 UTC by Mike A. Harris
Modified: 2005-04-02 20:36 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
[FIXED_X11R68x] xorg-x11-6.8.1-libX11-stack-overflow.patch (458 bytes, patch)
2004-09-24 04:28 UTC, Mike A. Harris
roland.mainz: 6.8-branch+
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mike A. Harris 2004-09-24 04:23:02 UTC
Xlib contains a stack overflow which was discovered by Arjan van de Ven when
recompiling X.Org X11 6.8.1 with gcc4 modified with new security features that
are under development which can autodetect many common buffer overflows at
compiletime and runtime.

The stack overflow was detected at compiletime and occurs in the file
xc/lib/X11/XKBBind.c in function XkbRefreshKeyboardMapping() on line #366:


    if (event->xkb_type==XkbMapNotify) {
        XkbMapChangesRec        changes;
        Status                  rtrn;

        if (xkbi->flags&XkbMapPending)
             changes= xkbi->changes;
----->  else bzero(&changes,sizeof(XkbChangesRec));
        XkbNoteMapChanges(&changes,event,XKB_XLIB_MAP_MASK);


I investigated this issue and found the following:

The "changes" structure is of type "XkbMapChangesRec", however bzero is
being called to zero it out with a size of "sizeof(XkbChangesRec)" which
is incorrect.  Both of these structures are defined in the header
xc/include/extensions/XKBstr.h as follows:

typedef struct _XkbMapChanges {
        unsigned short           changed;
        KeyCode                  min_key_code;
        KeyCode                  max_key_code;
        unsigned char            first_type;
        unsigned char            num_types;
        KeyCode                  first_key_sym;
        unsigned char            num_key_syms;
        KeyCode                  first_key_act;
        unsigned char            num_key_acts;
        KeyCode                  first_key_behavior;
        unsigned char            num_key_behaviors;
        KeyCode                  first_key_explicit;
        unsigned char            num_key_explicit;
        KeyCode                  first_modmap_key;
        unsigned char            num_modmap_keys;
        KeyCode                  first_vmodmap_key;
        unsigned char            num_vmodmap_keys;
        unsigned char            pad;
        unsigned short           vmods;
} XkbMapChangesRec,*XkbMapChangesPtr;

typedef struct _XkbChanges {
        unsigned short           device_spec;
        unsigned short           state_changes;
        XkbMapChangesRec         map;
        XkbControlsChangesRec    ctrls;
        XkbIndicatorChangesRec   indicators;
        XkbNameChangesRec        names;
        XkbCompatChangesRec      compat;
} XkbChangesRec, *XkbChangesPtr;


Observe that the XkbChangesRec struct is much larger than the XkbMapChangesRec
struct, and actually contains a member of type XkbMapChangesRec.  As such, the
call to bzero to zero out the "changes" struct overflows, and data on the
stack is corrupted.

A preliminary examination of the effects of the overflow seem to show no
security issues would be caused by this other than application failure.

I have written a patch to fix this problem which replaces the faulty
bzero call in a manner similar to other locations in the code, as
follows:

-        bzero(&changes,sizeof(XkbChangesRec));
+        bzero(&changes,sizeof(changes));


I have not yet examined the 6.7.0 release to see if the same issue is
present, but I assume it is.  The patch I've written should be applied
to CVS HEAD, as well as the 6.8 branch (and 6.7 stable branch if the
problem exists there also), as it is a clean and obviously correct fix.

Attaching patch to fix this issue.
Comment 1 Mike A. Harris 2004-09-24 04:28:13 UTC
Created attachment 966 [details] [review]
[FIXED_X11R68x] xorg-x11-6.8.1-libX11-stack-overflow.patch
Comment 2 Bugzilla Maintainer 2004-09-24 07:36:52 UTC
Seems like a good analysis.

Go for it...

Sounds like the new compiler is nice stuff, if it is able to expose latent bugs :-).
Comment 3 Roland Mainz 2004-11-19 07:31:22 UTC
Comment on attachment 966 [details] [review]
[FIXED_X11R68x] xorg-x11-6.8.1-libX11-stack-overflow.patch

Approved for the X11R6.8.x branch in the 2004-11-17 release-wranglers phone
call.
Please don't commit it yourself, I'll handle that once the CVS service is
available again.
Comment 4 Roland Mainz 2004-12-12 18:43:37 UTC
Comment on attachment 966 [details] [review]
[FIXED_X11R68x] xorg-x11-6.8.1-libX11-stack-overflow.patch

Patch checked-in into X11R6.8.x stable branch:

/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.365.2.28; previous revision: 1.365.2.27
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
/cvs/xorg/xc/lib/X11/XKBBind.c,v  <--  XKBBind.c
new revision: 1.2.4.1; previous revision: 1.2
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
Mailing the commit message to xorg-commit@lists.freedesktop.org...
Comment 5 Mike A. Harris 2005-01-25 06:40:05 UTC
Did this get checked into CVS HEAD also?  If not, why not?
Comment 6 Adam Jackson 2005-04-03 14:36:59 UTC
mass update: the fix for this bug was applied to both HEAD and the stable 6.8 branch, but the bug was 
never closed.  closing now.


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.