Description of problem:
The patch in XFree86-4.3.0-95.EL is (essentially) to copy bpr bytes (the size of
the dest), not bitmap->pitch bytes (the size of the source). Clearly one
doesn't want to overwrite beyond the dest size, but also one shouldn't read
beyond the source size.
ie if bpr > bitmap->pitch then we copy too much from the source data,
potentially corrupting data (at least the font glyphs).
How reproducible:
Well, with mozilla binaries from mozilla.org (ok, I *should* be using your rpms
but we started using the mozilla.org binaries before you started updating to
current versions), if one tries to view a webpage like
http://rhn.redhat.com/errata/rhel3as-errata.html then you see corrupted fonts.
The mozilla rpm doesn't show this since it uses a different font mechanism, but
arbitrary X apps *might* try to use whichever font this happens to have picked.
Steps to Reproduce:
1. install mozilla.org binaries
2. view http://rhn.redhat.com/errata/rhel3as-errata.html
3.
Actual results:
every char is corrupted (and stays corrupted if one scales with Ctrl+/-)
Expected results:
Normal chars.
Additional info:
Adding debugging to the code:
} else if(dx == 0) {
+ #include <syslog.h>
+ int minbpr=MIN(bpr, bitmap->pitch);
+ /* JSP debugging */
+ syslog(LOG_ERR, "JSP2: here in dx=0 case bpr=%d bitmap->pitch=%d mbpr=%d\
n",
+ bpr, bitmap->pitch, minbpr);
+
results in syslog messages like:
Sep 19 20:52:49 cheaptest xfs[4827]: JSP2: here in dx=0 case bpr=4
bitmap->pitch=0 mbpr=0
Sep 19 20:52:49 cheaptest xfs[4827]: JSP2: here in dx=0 case bpr=4
bitmap->pitch=0 mbpr=0
Sep 19 20:52:49 cheaptest xfs[4827]: JSP2: here in dx=0 case bpr=4
bitmap->pitch=2 mbpr=2
Sep 19 20:52:49 cheaptest last message repeated 187 times
so bpr > bitmap->pitch causing the memcpy code to copy more than is in the source...
I've attached a replacement for XFree86-4.3.0-xfs-rowstride-fix.patch which
copies MIN(bpr, bitmat->pitch) which seems to correct the problem for me, but
I'd be grateful if some wiser eyes could check it...
Sorry that the description on how to reproduce is so obscure, I really can't
(yet) find any other way to trigger this!

With the debugging (from above) added to print out bpr/bitmap->pitch the
following will show a case where this happens and bpr > bitmap->pitch.
FNT='-b&h-luxi sans-medium-r-normal--24-0-0-0-p-0-iso8859-1'
showfont -server unix/:7100 -fnt "$FNT" | more
You will get logged messages about bpr=1 bitmap->pitch=0 (for example)
It doesn't show the bitmap corruption in this case but at least it does show
that bpr isn't always the right size to copy (I hope)
I'l still trying to work out if mozilla is usine some unusual font or if it is
just the combination of fonts it asks for which causes the glyph corruption.

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/RHBA-2005-787.html