Red Hat Bugzilla – Bug 168729
xfs-rowstride-fix is wrong
Last modified: 2007-11-30 17:07:08 EST
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!
Created attachment 119001 [details] replacement patch for xfs-stride
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.
Thanks for the report, and suggested patch. Adding to review queue. Once we've reviewed the patch and done an investigation, we'll provide a status update, etc. Thanks again.
I Created a new bug 169021 about font problems. Could this be related?
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
*** Bug 169021 has been marked as a duplicate of this bug. ***
Fixed in XFree86-4.3.0-97.EL