> > Yes, it works correctly, so I assume that it doesn't use the extra > bytes. It is however not just reading uninitialized memory (which > valgrind usually tracks correctly), but it reads unallocated memory. > It is also interesting that it doesn't read beyond the bounds for > small sizes, so it seems like there is some smart logic that doesn't > work. The are all aligned reads, so they are known to be in valid memory. > > The example do however also show that it writes unallocated memory. > That looks like a genuine buffer overflow which could have security > implications? That would seem worrisome unless you look at the code:
590 <http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#590> /* UMR? See comments above. */ 591 <http://mxr.mozilla.org/mozilla/source/security/nss/lib/freebl/arcfour.c#591> *pOutWord <http://mxr.mozilla.org/mozilla/ident?i=pOutWord> = (*pOutWord <http://mxr.mozilla.org/mozilla/ident?i=pOutWord> & ~mask <http://mxr.mozilla.org/mozilla/ident?i=mask>) | ((inWord <http://mxr.mozilla.org/mozilla/ident?i=inWord> ^ streamWord <http://mxr.mozilla.org/mozilla/ident?i=streamWord>) & mask <http://mxr.mozilla.org/mozilla/ident?i=mask>); The UMR comment is the same one Brian pointed out. You can see that we are doing a read/modify/write. The bits outside the boundary are preserved. bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
