linux-kernel - Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL pointer dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080724.150920.120141367.davem@davemloft.net>
Date:	Thu, 24 Jul 2008 15:09:20 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	torvalds@...ux-foundation.org
Cc:	kaber@...sh.net, penberg@...helsinki.fi, mingo@...e.hu,
	herbert@...dor.apana.org.au, w@....eu, davidn@...idnewall.com,
	akpm@...ux-foundation.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, stefanr@...6.in-berlin.de,
	rjw@...k.pl, ilpo.jarvinen@...sinki.fi, davej@...hat.com
Subject: Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL
 pointer dereference

From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Thu, 24 Jul 2008 14:13:42 -0700 (PDT)

> Finally, why do the "ct->ext" dereference thing, when we know it has
> to be equal to "new"?

Actually in the old code this precondition didn't hold, which explains
how it is.

The old code looked like:

	if (newlen >= ksize(ct->ext)) {
		new = kmalloc(newlen, gfp);
		if (!new)
			return NULL;
 ...
		ct->ext = new;
	}

	ct->ext->offset[id] = newoff;
	ct->ext->len = newlen;
	memset((void *)ct->ext + newoff, 0, newlen - newoff);
	return (void *)ct->ext + newoff;

and in that context 'new' is only assigned in the "newlen >=" guarded
code block.

Anyways, it does seem that we should indeed only update the
new larger length only after we've initialized the contents.

Note that we could make krealloc() and friends clear out the trailing
bits of the new buffer, and therefore the caller wouldn't even need to
be mindful of such things.

I don't know if that's desirable in general, probably it isn't.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/