There are several memory access bugs in fbBltOne() where the code
accesses memory beyond an allocated buffer.  If the end of the buffer
is aligned with a page boundary, and the next page is unmapped or
read-protected, this will invariably lead to a segmentation fault.

The first bug is in fbBltOne(), where under certain circumstances the
code will load bits it doesn't need, and might not even exists.  This
happens when all bits in the source bitmap are needed, but the bitmaps
are "unaligned" such that both startmask and endmask are non-zero.
I'm pretty sure the attached patch fixes this.

The other bugs are in fbBltOne24(), which will virtually always read
beyond the end of a buffer.  Problem here is that the code
unconditionally tries to load the next stipple bits, even if they're
not needed.  The typical pattern is

    while (height--)
    {
        fbInitStipBits(...);
	if (leftmask)
        {
            ...
	    fbNextStipBits(...);
        }
	nl = nlMiddle
        while (nl--)
	{
	    ....
->	    fbNextStipBits(...);
	}
	...
    }

So even if NL == 0, this code reads in the next unit of bits from the
source bitmap.  There is no guarantee that those bits are present.

I have serious problems wrapping my head around this code, and I don't
have any 24bpp hardware to test things on.  But I have several Xorg
coredumps from other OpenBSD users that leave no doubt that this is
happening.  Can someone who is familliar with this code please take a
look at it.  These are serious bugs.

Mark


Index: fbbltone.c
===================================================================
RCS file: /cvs/XF4/xc/programs/Xserver/fb/fbbltone.c,v
retrieving revision 1.2
diff -u -p -r1.2 fbbltone.c
--- fbbltone.c 3 Nov 2004 00:07:51 -0000 1.2
+++ fbbltone.c 13 Aug 2005 14:15:07 -0000
@@ -257,7 +257,7 @@ fbBltOne (FbStip    *src,
 	srcinc++;
     if (endmask)
     {
-	endNeedsLoad = nDst % unitsPerSrc == 0;
+	endNeedsLoad = nmiddle % unitsPerSrc == 0;
 	if (endNeedsLoad)
 	    srcinc++;
     }