Date: Tue, 27 Mar 2001 18:10:30 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: obrien@FreeBSD.org, alpha@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu>, Mark Murray <mark@grondar.za> Subject: Re: dump(8) (vfs_object_create() panics: found the problem) Message-ID: <XFMail.010327181030.jhb@FreeBSD.org> In-Reply-To: <XFMail.010327165830.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28-Mar-01 John Baldwin wrote:
>
> On 27-Mar-01 Mark Murray wrote:
>>> Ok, as I said earlier, only the pointer to the vnop function table is
>>> spammed, the rest of the vnode is ok. I tracked this down to the big
>>> /dev/random overhaul commits of March 11. Removing 'device random'
>>> from my kernel gets rid of the panic but breaks ssh. :( A kernel just
>>> before the Mar 11 /dev/random commits boots fine, and one just after
>>> panics. :( Hopefully Mark can trace down where the data corruption is
>>> coming from. I'm willing to test any patches.
>>
>> Very weird.
>>
>> Please comment out all the *rijndael* function calls in hash.c and
>> see if that fixes anything? (I'm suspecting a stack-smash in the
>> rijndael encryption routines).
>
> I've narrowed it down to the rijndael_blockEncrypt() in yarrow_encrypt().
> Probably it is a buffer overflow of the d_out buffer passed in to that
> function. Now I'm off to check all the callers of yarrow_encrypt().
Ok, looking at the calls to yarrow_encrypt(), all the ones that use &genval are
probably bogus. genval is only a 64bit integer, but yarrow_encrypt() assumes
that it has KEYSIZE bytes to work with. From looking at the Rijndael code,
KEYSIZE needs to be at least 16 bytes before it does anything, and checking
the headers it is in fact 32 bytes long, or about 24 bytes longer than
genval :(. Since genval is static, it's in the data segment, and when you
overflow it you end up spewing random data into other variables. At least you
can have comfort in knowing that the faulting address was rather random.
Patch included below:
Index: yarrow.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.33
diff -u -r1.33 yarrow.c
--- yarrow.c 2001/03/10 12:51:55 1.33
+++ yarrow.c 2001/03/28 01:04:18
@@ -255,7 +255,7 @@
u_int
read_random_real(void *buf, u_int count)
{
- static u_int64_t genval;
+ static char genval[KEYSIZE];
static int cur = 0;
static int gate = 1;
u_int i;
@@ -302,8 +302,7 @@
else {
retval = cur < count ? cur : count;
memcpy(buf,
- (char *)&genval +
- (sizeof(random_state.counter) - cur),
+ &genval[(sizeof(random_state.counter) - cur)],
retval);
cur -= retval;
}
The second hunk is mostly a style change (I hate pointer arith), you could
probably get away with just removing the now unneeded (char *) cast. With this
my alpha is back to working, and now I can get back to breaking current with
more SMPng commits. This probably causes some kind of data corruption on x86,
too.
--
John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010327181030.jhb>