l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Dec 02 00:01

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] 2.4.20 zlib support?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] 2.4.20 zlib support?

Peter Jay Salzman said:
> there's a new "major catagory" in 2.4.20: "library routines".  under
> that, there are two options: compression and decompression support for
> zlib.  no help files for it.
> anyone know what kernel-space libz style support is for?  is the kernel
> now compressing portions of itself on the fly or something zany like
> that?

I had a guess on the purpose... (background)

Issues have come up with zlib in the past. Older copies of the zlib libs
permited exploits and this lead to headlines in bugtraq for a while. The
problems in zlib were *big*. Many apps use zlib, and though many dyn link
against the zlib on your system, not all need to do this, and some link to
zlib staticly. (This meant upgrading you zlib may not be enough to
"secure" the system against zlib expolts.) Then again, some are
commercial/proprietary and though "strings" may provide you with some
information in the application, that is not guarantee for detecting use of
zlib in an application. (obfuscation, etc.)

I seem to recall the bug in zlib that was exploited was based on
allocation of space for decompressing not being big enough for the actual
content (carefully crafted content).

My guess, was that the zlib kernel routines are designed to permit the
kernel to deal with this issue by controlling the space allocation and
allowing an extra layer of security if an application should use an
insecure zlib.

Now, the actual content of the docs suggest there is a relation to this.
It appears as though the zlib stuff for 2.4.20 is a replacement for zlib.
However, it appears as though apps must use the provided *.h files before
they can take advantage of this.

From: /usr/src/linux-2.4.20/lib/zlib_inflate/Makefile :
# This is a modified version of zlib, which does all memory
# allocation ahead of time.
# This is only the decompression, see zlib_deflate for the
# the compression
# Decompression needs to be serialized for each memory
# allocation.
# (The upsides of the simplification is that you can't get in
# any nasty situations wrt memory management, and that the
# uncompression can be done without blocking on allocation).

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.