Bug 132885 - libX11 overflows it's own stack
libX11 overflows it's own stack
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brian Stein
David Lawrence
Depends On:
Blocks: 143573
  Show dependency treegraph
Reported: 2004-09-18 14:03 EDT by Brian Stein
Modified: 2013-03-01 00:14 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-30 03:28:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Arjan van de Ven 2004-09-18 14:03:42 EDT
Description of problem:

in file sc/lib/X11/XKBBind.c line 336-ish, there is

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

note the mismatching type in the sizeof() for bzero(); XkbChangesRec
is actually bigger than a XkbMapChangesRec so this corrupts the stack.
Comment 2 Mike A. Harris 2004-09-21 21:53:32 EDT
Status update:  We discussed this issue on today's team confcall and
Kevin indicated that he did a preliminary investigation of this in
which it seemed that there is no real overflow.

Further investigation is needed in order to be conclusive, and also
to determine what if any real actual security implications there are
if any.

Setting FC3Target status for tracking.  If further investigation
ends up concluding there is a real issue, we can raise this to
FC3Blocker and/or security update priority.
Comment 3 Arjan van de Ven 2004-09-22 02:34:03 EDT
gcc detected an actual real overflow *AND* will kill the X server when
this code runs.
Comment 4 Mike A. Harris 2004-09-22 04:57:48 EDT
The X server isn't linked to libX11.  ;o)
Comment 5 Mike A. Harris 2004-09-22 06:06:00 EDT
Ok, I have done an investigation of this issue, and this is
definitely without question a bug in Xlib.  We've discussed this
on IRC quite extensively, but I will try to summarize here.

The function XkbRefreshKeyboardMapping() inside xc/lib/X11/XKBBind.c
contains the following code:

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

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

The "changes" struct is of type XkbMapChangesRec as defined above,
however bzero is zeroing out sizeof(XkbChangesRec), which is the
*wrong* structure typedef.  Examining the structure definitions
for both XkbMapChangesRec and XkbChangesRec, which are defined
in xc/include/extensions/XKBstr.h, we can see that the XkbChangesRec
structure is larger in size than the XkbMapChangesRec structure:

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;

Notice that XkbChangesRec actually contains an XkbMapChangesRec
structure, so it *has* to be larger.  As such, bzero is being
called with the incorrect structure being used in the sizeof(),
resulting in a stack overflow condition.

Examining the code further I've determined that the changes
struct is properly declared, and that the bzero call is incorrect.
The proper fix is to call bzero as:


I will be applying a patch to our 6.8.1 rpms to fix this issue,
and also examining all previous X releases to see if the same
problem is present there also.

I do not believe this issue is exploitable, since it is just
causing a fixed zeroing of part of the stack.  So no security
erratum should be necessary.

Comment 6 Mike A. Harris 2004-09-22 06:10:09 EDT
Reassigning this issue to myself, as I've already more or less
taken it over.
Comment 7 Mike A. Harris 2004-09-22 07:10:24 EDT
Going to file my patch upstream to X.Org tomorrow and discuss on
xorg mailing list, then commit to CVS, assuming there are no
objections raised.
Comment 8 Kevin E. Martin 2004-09-22 10:21:14 EDT
Just a clarification, I did an initial investigation of bug #132884
(see that bug for my comments there).  At that time, I had not looked
into this bug.

I agree with your assessment of this bug and your resolution.
Comment 9 Mike A. Harris 2004-09-24 06:04:30 EDT
Thanks Kevin, I misunderstood initially and thought you had
looked at both issues.

I've checked in my fix for this to internal CVS, and it will
be present in the 6.8.1-4 build.  Leaving bug report open until
the following items are complete:

1) Fix submitted upstream and checked into CVS

2) Investigate X.Org 6.7.0 to see if we need to patch it too

3) Investigate XFree86 4.3.0 to see if we need to patch it too

4) Investigate XFree86 4.1.0 to see if we need to patch it too

I'll provide status here as these items are completed.

Comment 10 Mike A. Harris 2004-09-24 07:29:14 EDT
Bug filed in X.Org bugzilla, with patch attached.

Comment 11 Mike A. Harris 2004-09-28 14:02:07 EDT
Patch also relevant and applied to xorg-x11-6.7.0.
Comment 12 Mike A. Harris 2004-09-28 14:04:20 EDT
Status:  Need to investigate RHEL 2.1 and 3 for U4.  Will probably
file separate bugs to track for those two unless I do it sometime
Comment 14 Mike A. Harris 2005-01-25 04:55:49 EST
Investigation indicates the problem exists in both RHEL 2.1 and
RHEL 3.  I've backported the patch to XFree86 4.1.0 and 4.3.0,
and applied them to CVS.

Status:  New rpms need to be built for RHEL2.1U7 and RHEL3U5 erratum
         in progress.
Comment 15 Mike A. Harris 2005-01-25 09:44:17 EST
XFree86-4.1.0-70.EL built for RHEL 2.1
XFree86-4.3.0-79.EL built for RHEL 3
Comment 18 Mike A. Harris 2005-01-25 12:55:18 EST
Setting to "MODIFIED" state, now that rpms are built for testing.
Comment 19 Mark J. Cox (Product Security) 2005-03-30 03:28:56 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.