2.4.36-pre1, Preventing NULL Dereferences

Submitted by Jeremy
on September 9, 2007 - 5:40am

"I've just released Linux 2.4.36-pre1," announced 2.4 maintainer Willy Tarreau. He described a new feature found in the first pre-release:

"In private discussions, Solar Designer proposed to restrict the ability to map the NULL address to CAP_RAW_IO capable processes only. The idea behind this was to prevent 'normal' users from trying to exploit NULL dereferences in the kernel which have not been discovered yet. This is purely a preventive measure."

Willy added that a similar feature exists in the 2.6 kernel, "Chris Wright noted that 2.6 already has a somewhat similar feature brought by Eric Paris, which introduces a sysctl by which the admin can set the lower mappable address." He also noted that the feature can be disabled, "Alan Cox indicated that it was desirable to be able to dynamically disable the feature because some (very) rare programs map the NULL pointer to speed up their walk through linked lists by avoiding NULL pointer checks." Finally he asked for testers, "please report any breakage you would detect when enabling it. We're pretty confident that almost every applications will not see any difference since no normal application maps NULL. But it would be interesting to identify the "special" ones."

People testing the latest 2.4 kernel will be unable to build it with gcc-4.2. Willy explained, "please note that this version _will not_ build under gcc-4.2, so it's not necessary to report it. I'll try to find a solution."

Source changes to the latest 2.4 kernel can be tracked online via the 2.4 gitweb interface. Willy noted that the 2.4.36 kernel will probably be released in late 2007, "I estimate that depending on what will be updated, 2.4.36 could see the light by the end of this year."


From:	Willy Tarreau [email blocked]
Subject: Linux 2.4.36-pre1
Date:	Sat, 8 Sep 2007 18:46:59 +0000

Hi,

I've just released Linux 2.4.36-pre1.

It's basically the same as 2.4.35.2, with an add-on I'd like people
to experiment with : In private discussions, Solar Designer proposed
to restrict the ability to map the NULL address to CAP_RAW_IO capable
processes only. The idea behind this was to prevent "normal" users
from trying to exploit NULL dereferences in the kernel which have
not been discovered yet. This is purely a preventive measure. Alan
Cox indicated that it was desirable to be able to dynamically disable
the feature because some (very) rare programs map the NULL pointer
to speed up their walk through linked lists by avoiding NULL pointer
checks.

Chris Wright noted that 2.6 already has a somewhat similar feature
brought by Eric Paris, which introduces a sysctl by which the admin
can set the lower mappable address. 

Finally a combination of both methods was implemented. The same sysctl
as in 2.6 was implemented to set the lowest mappable address for non
CAP_RAW_IO capable processes. By default, it is set to zero (disabled)
which means NULL is mappable for everybody. To enable protection,
simply echo the first mappable address into /proc/sys/vm/mmap_min_addr :

  # echo 4096 > /proc/sys/vm/mmap_min_addr

We chose to use the same sysctl and semantics as in 2.6 to ease the
transition from 2.4 to 2.6 without requiring to remove protection.

Extensive tests have been ran with this feature. Some of my desktop
machines already run with it enabled, and our appliances at Exceliance
ship with it enabled by default. Solar Designer tested both Xorg and
Wine as a normal user, and the same feature is enabled by default in
the Openwall Linux 2.4.35-ow2 kernel.

Please report any breakage you would detect when enabling it. We're
pretty confident that almost every applications will not see any
difference since no normal application maps NULL. But it would be
interesting to identify the "special" ones. Applications running
as root will never be impacted. Depending on the application,
typical breakage would translate into memory allocation error or
segmentation fault. Something clearly detectable anyway.

Another issue I'll try to get solved is the current status of the
e100 driver. I got hit in production by its very unreliable VLAN
support (version 2.3.43 !). I got 3.5.17 to fix all of my issues,
so I'll check with the e100 maintainers if we can upgrade it. It
will make the maintenance easier for them too by getting rid of
a very old and buggy version.

Last but not least, please note that this version _will not_ build
under gcc-4.2, so it's not necessary to report it. I'll try to find
a solution.

I estimate that depending on what will be updated, 2.4.36 could see
the light by the end of this year. 2.4.35.x will still evolve in
parallel, of course !

Willy
--

The patch and changelog will appear soon at the following locations:
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.36-pre1.bz2
  ftp://ftp.all.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.36.log

Git repository:
   git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4.git
  http://www.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-2.4.git/

Git repository through the gitweb interface:
  http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git


Summary of changes from v2.4.35 to v2.4.36-pre1
============================================

Marc Haisenko (1):
      b44: fix force mac address before ifconfig up

Willy Tarreau (12):
      build fix for lvm with gcc 4
      fix wdt83627 build breakage with gcc 4.x
      wdt83627: fix wdt_init() return code
      module fdomain_cs requires fdomain_setup()
      do not use gcc's builtin strpbrk
      fix incorrect use of -fno-unit-at-a-time on GCC >= 4
      second build fix for some rare buggy versions of GCC 4
      CVE-2007-3848 Privilege escalation via PR_SET_PDEATHSIG
      i386: do_test_wp_bit() must not be inlined
      restore -fno-unit-at-a-time on GCC >= 4
      sysctl to prevent normal processes from mapping NULL
      Change VERSION to 2.4.36-pre1


Related Links:

No new features...

Fred Flinta (not verified)
on
September 9, 2007 - 6:41am

No new features in in the 2.4 kernel branch.

2.4 is only for fix bugs, not add new features.

Switch to 2.6.

Hey... You could always fork

Anonymous (not verified)
on
September 9, 2007 - 7:47am

Hey...

You could always fork your own 2.4 branch where you decide what is considered a feature and what a bug fix.

Oh really...

curley95 (not verified)
on
September 10, 2007 - 11:57am

Why is that?

I still support a VERY LARGE number of machines that are on the 2.4.x kernel. Yes its a pain, but they still work nicely and going to 2.6 in-place wouldn't be pretty AT ALL.

No these are not machines that follow the "apt-get update && apt-get -u upgrade && apt-get -u dist-upgrade" methods.

But, YUM sort of works. Plus we have some pieces tied ONLY to the 2.4. kernel (think early RLX blades) and a proprietary DB that we are migrating away from which requires a 2.4 kernel version or pay HYARGE amounts to get the newer 2.6 kernel... nope sorry, you priced yourself out of the market.

ABWlwWtbxHnNJthiK

cool (not verified)
on
January 6, 2008 - 7:08am

sdklfjsdlfksdjf

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.