Changelog from 2.4.32-hf32.1 to 2.4.32-hf32.2 --------------------------------------- '+' = added ; '-' = removed + 2.4.32-wan-sdla-fix-probable-security-hole-1 (Horms) [PATCH] wan sdla: fix probable security hole Quoting Chris Wright : "Hrm, I believe you could use this to read 128k of kernel memory. sdla_read() takes len as a short, whereas mem.len is an int. So, if mem.len == 0x20000, the allocation could still succeed. When cast to short, len will be 0x0, causing the read loop to copy nothing into the buffer. At least it's protected by a capable() check. I don't know what proper upper bound is for this hardware, or how much it's used/cared about. Simple memset() is trivial fix." This seems to be applicable to 2.4. + 2.4.32-CAN-2004-1058-proc_pid_cmdline-race-fix-1 (dann frazier) The following patch fixes a race condition that allows local users to view the environment variables of another process. Taken from Red Hat's kernel-2.4.21-27.0.4.EL.src.rpm. + 2.4.32-bond_alb-hash-table-corruption-1 (ODonnell, Michael) Our systems have been crashing during testing of PCI HotPlug support in the various networking components. We've faulted in the bonding driver due to a bug in bond_alb.c:tlb_clear_slave(). In that routine, the last modification to the TLB hash table is made without protection of the lock, allowing a race that can lead tlb_choose_channel() to select an invalid table element. + 2.4.32-rc2-mcast-filter-1 (Willy Tarreau) [PATCH-2.4][MCAST]IPv6: small fix for ip6_mc_msfilter(...) Multicast source filters aren't widely used yet, and that's really the only feature that's affected if an application actually exercises this bug, as far as I can tell. An ordinary filter-less multicast join should still work, and only forwarded multicast traffic making use of filters and doing empty-source filters with the MSFILTER ioctl would be at risk of not getting multicast traffic forwarded to them because the reports generated would not be based on the correct counts. Initial 2.6 patch by Yan Zheng, bug explanation by David Stevens, patch ACKed by David. Changelog from 2.4.32 to 2.4.32-hf32.1 --------------------------------------- '+' = added ; '-' = removed + 2.4.32-backport-of-CVE-2005-2709-fix-1 (dann frazier) I've backported the fix for CVE-2005-2709 to 2.4 for Debian's 2.4 sarge kernel. sysctl.c in Linux kernel before 2.6.14.1 allows local users to cause a denial of service (kernel oops) and possibly execute code by opening an interface file in /proc/sys/net/ipv4/conf/, waiting until the interface is unregistered, then obtaining and modifying function pointers in memory that was used for the ctl_table. + 2.4.32-ipv6-fix-refcnt-of-struct-ip6_flowlabel-1 (Yan Zheng) This looks like another potential "local DoS" since this is in setsockopt(IPV6_FLOWLABEL_MGR). Users can cause a flow label to be kfreed() without removing it from the socket; and then overwrite its contents. This can trigger random kernel memory corruption. + 2.4.32-fix-sendmsg-overflow-CVE-2005-2490-1 (Marcus Meissner) Al Viro reported a flaw in sendmsg(). "When we copy 32bit ->msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Moreover, if original looks small enough, we end up copying to on-stack array." - CVE-2005-2490. + 2.4.32-vfs-local-denial-of-service-file-lease-1 (Horms) [PATCH] VFS: local denial-of-service with file leases (CVE-2005-3857) Remove time_out_leases() printk that's easily triggered by users. + 2.4.32-x86-64-user-code-panics-kernel-CVE-2005-2708-1 (Dave Anderson) There seems to be a local DoS in exec on AMD64 / linux 2.4 when the system is under memory pressure. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161925 + 2.4.32-IGMP-workaround-for-IGMP-v1-v2-bug-1 (David Stevens) As explained at http://www.cs.ucsb.edu/~krishna/igmp_dos/ With IGMP version 1 and 2 it is possible to inject a unicast report to a client which will make it ignore multicast reports sent later by the router. The fix is to only accept the report if is was sent to a multicast or unicast address. + 2.4.32-ipv6-mcast-igmp-dos-fix-1 (David S. Miller) Same issue as IPv4, don't listen to non-broadcast non-multicast reports. + 2.4.32-airo_cs-prototypes-1 (Adrian Bunk) If you got strange problems with either airo_cs devices or in any other completely unrelated part of the kernel shortly or long after a airo_cs device was detected by the kernel, this might have been caused by the fact that caller and callee disagreed regarding the size of the first argument to init_airo_card()... + 2.4.32-dont-panic-on-ide-dma-errors-1 (Chris Ross) Kernel 2.4.32 and earlier can panic when trying to read a corrupted sector from an IDE disk. The function ide_dma_timeout_retry can end a request early by calling idedisk_error, but then goes on to use the request anyway causing a kernel panic due to a null pointer exception. + 2.4.32-data-corruption-in-smb_proc_setattr_unix-1 (Maciej W. Rozycki) This patch fixes a data corruption in smb_proc_setattr_unix(). smb_filetype_from_mode() returns an u32, and there are only four bytes reserved for it in data. + 2.4.32-fix-for-clock-running-too-fast-1 (Akira Tsukamoto) This one line patch adds upper bound testing inside timer_irq_works() when evaluating whether irq timer works or not on boot up. It fix the machines having problem with clock running too fast. What this patch do is, if timer interrupts running too fast through IO-APIC IRQ then false back to i8259A IRQ. + 2.4.32-fix-ptrace-self-attach-rule-1 (Linus Torvalds) [PATCH] Fix ptrace self-attach rule Before we did CLONE_THREAD, the way to check whether we were attaching to ourselves was to just check "current == task", but with CLONE_THREAD we should check that the thread group ID matches instead. + 2.4.32-dcache-avoid-race-nr_unused-dentries-1 (Neil Brown) [PATCH] fs/dcache.c: avoid race when updating nr_unused count of unused dentries. d_count==1 is no guarantee that dentry is on the dentry_unused list, even if it has just been incremented inside dcache_lock, as dput can decrement at any time. This test from Greg Banks is much safer, and is more transparently correct.