bzImage -> vmlinux?

Bennett Todd bet at
Wed Jul 14 04:20:59 PDT 2004

I think you're still missing what I'm trying to say.

I understand about kernel and user space.

But you'd started me on this by writing:

> It is not considered 'secure' for this version of zlib to handle
> userspace zlib needs, although I have never been quite sure *why*
> this is, as theres nothing stopping the kernel zib code being
> mapped *read-only* into userspace...

and I'm trying to offer a possible explanation of *why*.

Forget readonly mapping. Forget page tables.

Think about, hypothetically, two implementations of zlib. The older
one (as found in the Linux kernel bootstrap-time decompressor) has
some bugs in it. The flavour of those bugs is that when fed suitably
crafted bogus input data, they allow an attacker to exploit a buffer
overrun or some such to jump into code found in the
attacker-provided input data. These bugs have been fixed in the
userspace libz.

Now, the kernel boot-time uncompressor isn't a problem; an attacker
who can rewrite the vmlinuz that's its input has already won,
there's nothing left to protect.

But if that same vulnerable uncompressor were used as the userspace
libz, anyone could run arbitrary code on your system if they could
get you to view their website --- just redirect to a compressed page
and ka-boom.

It's not code readonly/readwrite, it's not kernel pages -vs-
userspace pages, it's who provides the input that the uncompressor
is working on. Strangers get to feed the userspace uncompressor, and
we don't want those strangers able to run arbitrary code. The only
folks who can feed the kernel uncompressor are the folks who're
providing the compressed kernel image at boot time, they own the
system regardless.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the lfs-chat mailing list