[ANNOUNCE] Linux 2.4.32-hf32.7

From: Willy Tarreau
Date: Fri Jul 28 2006 - 12:23:42 EST


Hi All,

I finally put together my the remaining fixes for kernel 2.4.32.
Most are security-related. Note that I've created a 2.4-hf branch
in my git tree on kernel.org, that I will be able to feed faster
than releasing a complete hotfix. It will only be for the last
release, though.

I've built it with allmodconfig but not booted it. However, since
those patches are all present in 2.4.33-rc3, I'm confident.

I plan to move all this to kernel.org soon, but in the mean time,
it is still available at the usual places :

hotfixes home : http://linux.exosec.net/kernel/2.4-hf/
last version : http://linux.exosec.net/kernel/2.4-hf/LATEST/LATEST/
RSS feed : http://linux.exosec.net/kernel/hf.xml
build results : http://bugsplatter.mine.nu/test/linux-2.4/ (Grant's site)
GIT : http://linux.1wt.eu/kernel/2.4/patches-2.4-hf.git/
GITWEB : http://git.1wt.eu/git/?p=patches-2.4-hf.git;a=summary

There are 14 new patches in Kernel 2.4.32-hf32.7 (see below for details) :

- 2.4.32-CVE-2006-2935-dvd_read_bca-buffer-overflow-1 (Andreas Haumer)
- 2.4.32-ethtool-oopses-1 (Willy Tarreau)
- 2.4.32-ext3-block-bitmap-leakage-1 (Kirill Korotaev)
- 2.4.32-CVE-2006-0039-netfilter-possible-race-in-do_add_counters-1 (Solar Designer)
- 2.4.32-CVE-2006-1525-ip_route_input-panic-1 (Stephen Hemminger)
- 2.4.32-CVE-2006-1857-SCTP-parameter-length-in-hb-ack-1 (Vlad Yasevich)
- 2.4.32-CVE-2006-1858-SCTP-respect-chunk-length-1 (Vlad Yasevich)
- 2.4.32-CVE-2006-2271-SCTP-closed-state-1 (Sridhar Samudrala)
- 2.4.32-CVE-2006-2272-SCTP-fragmented-control-chunks-1 (Sridhar Samudrala)
- 2.4.32-CVE-2006-2274-SCTP-infinite-recursion-1 (Vladislav Yasevich)
- 2.4.32-netfilter-possible-overflow-in-do_replace-1 (Kirill Korotaev)
- 2.4.32-ACPI-range-checking-for-sleep-states-1 (Willy Tarreau)
- 2.4.32-buffer-overflow-in-usb-rndis-1 (Shaun Tancheff)
- 2.4.32-ext3-link-unlink-race-3 (Vadim Egorov)

This leads to the following number of patches per kernel :

Version | New | Total
--------+-----+------
2.4.28 | 14 | 191
2.4.29 | 14 | 188
2.4.30 | 14 | 122
2.4.31 | 14 | 109
2.4.32 | 14 | 59
--------+-----+------

Changelog from 2.4.32-hf32.6 to 2.4.32-hf32.7
---------------------------------------
'+' = added ; '-' = removed

+ 2.4.32-CVE-2006-2935-dvd_read_bca-buffer-overflow-1 (Andreas Haumer)

As described in CVE-2006-2935, a typo in cdrom.c causes a buffer
overflow in dvd_read_bca(). Use the same fix for 2.4 as for 2.6.
Discussion here :
http://bugzilla.kernel.org/show_bug.cgi?id=2966

+ 2.4.32-ethtool-oopses-1 (Willy Tarreau)

The function pointers which were checked were for their get_* counterparts.
Typically a copy-paste typo.

+ 2.4.32-ext3-block-bitmap-leakage-1 (Kirill Korotaev)

This patch fixes ext3 block bitmap leakage, which leads to "block bitmap
differences" fsck messages on healthy filesystem. All kernels up to 2.6.17
have this bug. Found by Vasily Averin and Andrey Savochkin. Test case
triggered the issue was created by Dmitry Monakhov.

+ 2.4.32-CVE-2006-0039-netfilter-possible-race-in-do_add_counters-1 (Solar Designer)

Solar Designer found a race condition in do_add_counters(). The beginning
of paddc is supposed to be the same as tmp which was sanity-checked
above, but it might not be the same in reality. In case the integer
overflow and/or the race condition are triggered, paddc->num_counters
might not match the allocation size for paddc. If the check below
(t->private->number != paddc->num_counters) nevertheless passes (perhaps
this requires the race condition to be triggered), IPT_ENTRY_ITERATE()
would read kernel memory beyond the allocation size, potentially causing
an oops or leaking sensitive data (e.g., passwords from host system or
from another VPS) via counter increments. This requires CAP_NET_ADMIN.

+ 2.4.32-CVE-2006-1525-ip_route_input-panic-1 (Stephen Hemminger)

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388
The bug is caused by ip_route_input dereferencing skb->nh.protocol of
the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
it). It only happens if the route requested is for a multicast IP
address.

+ 2.4.32-CVE-2006-1857-SCTP-parameter-length-in-hb-ack-1 (Vlad Yasevich)

If SCTP receives a badly formatted HB-ACK chunk, it is possible
that we may access invalid memory and potentially have a buffer
overflow. We should really make sure that the chunk format is
what we expect, before attempting to touch the data.

+ 2.4.32-CVE-2006-1858-SCTP-respect-chunk-length-1 (Vlad Yasevich)

When performing bound checks during the parameter processing, we
want to use the real chunk and paramter lengths for bounds instead
of the rounded ones. This prevents us from potentially walking of
the end if the chunk length was miscalculated. We still use rounded
lengths when advancing the pointer. This was found during a
conformance test that changed the chunk length without modifying
parameters.

+ 2.4.32-CVE-2006-2271-SCTP-closed-state-1 (Sridhar Samudrala)

Discard an unexpected chunk in CLOSED state rather can calling BUG().

+ 2.4.32-CVE-2006-2272-SCTP-fragmented-control-chunks-1 (Sridhar Samudrala)

Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
are received as skb's with fragment list.

+ 2.4.32-CVE-2006-2274-SCTP-infinite-recursion-1 (Vladislav Yasevich)

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system. The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself. This causes
sctp_skb_pull() to potentially recurse indefinitely. Proposed solution is
to make a copy of the skb when attempting to link things using frag_list.

+ 2.4.32-netfilter-possible-overflow-in-do_replace-1 (Kirill Korotaev)

netfilter's do_replace() can overflow on addition within SMP_ALIGN()
and/or on multiplication by NR_CPUS, resulting in a buffer overflow on
the copy_from_user(). In practice, the overflow on addition is
triggerable on all systems, whereas the multiplication one might require
much physical memory to be present due to the check above. Either is
sufficient to overwrite arbitrary amounts of kernel memory. Found by
Solar Designer during security audit of OpenVZ.org

+ 2.4.32-ACPI-range-checking-for-sleep-states-1 (Willy Tarreau)

A range checking is missing in acpi_system_write_sleep() in kernel
2.4, and writing a large integer value to /proc/acpi/sleep will cause
an oops. Fix extracted from the PaX patch.

+ 2.4.32-buffer-overflow-in-usb-rndis-1 (Shaun Tancheff)

Remote NDIS response to OID_GEN_SUPPORTED_LIST only allocated space
for the data attached to the reply, and not the reply structure
itself. This caused other kmalloc'd memory to be corrupted.

+ 2.4.32-ext3-link-unlink-race-3 (Vadim Egorov)

The problem happens when link and unlink are invoked simultaneously on the
same inode on ext3 filesystem. In this case ext3_unlink may decrement
i_nlink to 0 and put this inode into the in-memory orphan list, while
ext3_link will increment i_nlink back to 1 having the inode in the orphan
list. Thus the system ends up having an inode with i_nlink == 1 in the
orphan list. When this inode gets unused later the memory might get
released to the free pool and then be used for some other purpose, most
likely some other inode. From this point on any operation on the orphan
list may result in modification of the list_head that could alredy be used
to store some other date. Solution: keep a copy of the inode pointer,
incrementing its reference counter, to fix the situation.


Regards,
Willy
PGP Fingerprint : 72C2 A394 02EA F546 BA6F A7B1 E82C B631 848A 1004

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/