"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
No new features...
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
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...
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
sdklfjsdlfksdjf