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.

gcc detected an actual real overflow *AND* will kill the X server when
this code runs.

The X server isn't linked to libX11.  ;o)

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));
        XkbNoteMapChanges(&changes,event,XKB_XLIB_MAP_MASK);
        LockDisplay(dpy);

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:

    bzero(&changes,sizeof(changes));

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.

Reassigning this issue to myself, as I've already more or less
taken it over.

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.

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.

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.

Bug filed in X.Org bugzilla, with patch attached.

https://freedesktop.org/bugzilla/show_bug.cgi?id=1459

Patch also relevant and applied to xorg-x11-6.7.0.

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
soon.

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.

XFree86-4.1.0-70.EL built for RHEL 2.1
XFree86-4.3.0-79.EL built for RHEL 3

Setting to "MODIFIED" state, now that rpms are built for testing.

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.

http://rhn.redhat.com/errata/RHSA-2005-331.html