Commit: c6eeec0fc71b38b39a2fa2f31b4f67edeeb36a25 Author: Adrian Bunk Fri, 13 Apr 2007 16:47:54 +0200 Linux 2.6.16.47 Commit: 15a0dd9aa4a748d403f32ef97311230412ba5b5c Author: Adrian Bunk Tue, 10 Apr 2007 23:07:31 +0200 Linux 2.6.16.47-rc1 Commit: 132d8d23a0a2726fb2375fcac89119e28858eb6f Author: Jean Delvare Tue, 10 Apr 2007 23:06:06 +0200 APPLETALK: Fix a remotely triggerable crash (CVE-2007-1357) When we receive an AppleTalk frame shorter than what its header says, we still attempt to verify its checksum, and trip on the BUG_ON() at the end of function atalk_sum_skb() because of the length mismatch. This has security implications because this can be triggered by simply sending a specially crafted ethernet frame to a target victim, effectively crashing that host. Thus this qualifies, I think, as a remote DoS. Here is the frame I used to trigger the crash, in npg format: { # Ethernet header ----- XX XX XX XX XX XX # Destination MAC 00 00 00 00 00 00 # Source MAC 00 1D # Length # LLC header ----- AA AA 03 08 00 07 80 9B # Appletalk # Appletalk header ----- 00 1B # Packet length (invalid) 00 01 # Fake checksum 00 00 00 00 # Destination and source networks 00 00 00 00 # Destination and source nodes and ports # Payload ----- 0C 0D 0E 0F 10 11 12 13 14 } The destination MAC address must be set to those of the victim. The severity is mitigated by two requirements: * The target host must have the appletalk kernel module loaded. I suspect this isn't so frequent. * AppleTalk frames are non-IP, thus I guess they can only travel on local networks. I am no network expert though, maybe it is possible to somehow encapsulate AppleTalk packets over IP. The bug has been reported back in June 2004: http://bugzilla.kernel.org/show_bug.cgi?id=2979 But it wasn't investigated, and was closed in July 2006 as both reporters had vanished meanwhile. This code was new in kernel 2.6.0-test5: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2 And not modified since then, so we can assume that vanilla kernels 2.6.0-test5 and later, and distribution kernels based thereon, are affected. Note that I still do not know for sure what triggered the bug in the real-world cases. The frame could have been corrupted by the kernel if we have a bug hiding somewhere. But more likely, we are receiving the faulty frame from the network. Signed-off-by: Jean Delvare Signed-off-by: Adrian Bunk Commit: e6f8caf0c41f27510c8a0c43a29b2e6f62a2dc56 Author: Sergei Shtylyov Mon, 09 Apr 2007 01:16:18 +0200 siimage: PIO1/2 taskfile transfer overclocking fix Fix two typos found by SiI680A documentation check. They caused the taskfile transfer overclocking: - in PIO mode 1 as 0x2283 must be used for both data and taskfile transfers; - in PIO mode 2 as data and taskfile timings are swapped when writing to the MMIO regs. Fix coding style and trailing whitespace in enclosing statements while at it... Signed-off-by: Sergei Shtylyov Signed-off-by: Adrian Bunk Commit: 75da4e64268ffdbd56143b4642d340b9bf3ee350 Author: Thomas Gleixner Mon, 09 Apr 2007 01:04:23 +0200 hrtimer: prevent overrun DoS in hrtimer_forward() hrtimer_forward() does not check for the possible overflow of timer->expires. This can happen on 64 bit machines with large interval values and results currently in an endless loop in the softirq because the expiry value becomes negative and therefor the timer is expired all the time. Check for this condition and set the expiry value to the max. expiry time in the future. Signed-off-by: Thomas Gleixner Signed-off-by: Adrian Bunk Commit: 19b5054d01f856a189659a59b24c8497b038cb43 Author: Thomas Gleixner Mon, 09 Apr 2007 00:54:30 +0200 fix MTIME_SEC_MAX on 32-bit The maximum seconds value we can handle on 32bit is LONG_MAX. Signed-off-by: Adrian Bunk Commit: 812b03dc31229847825989f5e35359a7c4dff6f4 Author: Thomas Gleixner Mon, 09 Apr 2007 00:03:30 +0200 prevent timespec/timeval to ktime_t overflow Frank v. Waveren pointed out that on 64bit machines the timespec to ktime_t conversion might overflow. This is also true for timeval to time_t conversions. This breaks a "sleep inf" on 64bit machines. While a timespec/timeval with tx.sec = MAX_LONG is valid by specification the internal representation of ktime_t is based on nanoseconds. The conversion of seconds to nanoseconds overflows for seconds values >= (MAX_LONG / NSEC_PER_SEC). Check the seconds argument to the conversion and limit it to the maximum time which can be represented by ktime_t. Signed-off-by: Thomas Gleixner Signed-off-by: Adrian Bunk Commit: 2c461b3302b33de1500267a11cc50e29f33cbde6 Author: David Moore Sun, 08 Apr 2007 23:54:41 +0200 ieee1394: video1394: DMA fix This together with the phys_to_virt fix in lib/swiotlb.c::swiotlb_sync_sg fixes video1394 DMA on machines with DMA bounce buffers, especially Intel x86-64 machines with > 3GB RAM. Signed-off-by: David Moore Signed-off-by: Stefan Richter Signed-off-by: Adrian Bunk Commit: f95540a5193f909b5700555ceafc69bcb13d2174 Author: Eric W. Biederman Sun, 08 Apr 2007 23:47:24 +0200 Fix reparenting to the same thread group. (take 2) This patch fixes the case when we reparent to a different thread in the same thread group. This modifies the code so that we do not send signals and do not change the signal to send to SIGCHLD unless we have change the thread group of our parents. It also suppresses sending pdeath_sig in this cas as well since the result of geppid doesn't change. Thanks to Oleg for spotting my bug of only fixing this for non-ptraced tasks. This fixes the issues identified by Albert Cahalan in thread http://lkml.org/lkml/2006/12/21/22 Signed-off-by: Eric W. Biederman Signed-off-by: Adrian Bunk Commit: 928fb605c9107cc5c4e4e77d99ea455651a4635f Author: Stephen Hemminger Sun, 08 Apr 2007 23:45:04 +0200 tcp: fix cubic scaling error Doug Leith observed a discrepancy between the version of CUBIC described in the papers and the version in 2.6.18. A math error related to scaling causes Cubic to grow too slowly. Patch is from "Sangtae Ha" . I validated that it does fix the problems. See the following to show behavior over 500ms 100 Mbit link. Sender (2.6.19-rc3) --- Bridge (2.6.18-rt7) ------- Receiver (2.6.19-rc3) 1G [netem] 100M http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-orig.png http://developer.osdl.org/shemminger/tcp/2.6.19-rc3/cubic-fix.png Signed-off-by: Stephen Hemminger Signed-off-by: Adrian Bunk Commit: 289a332c20458518f27f4a32fe2a69364489c782 Author: Jeff Garzik Wed, 04 Apr 2007 23:45:53 +0200 [netdrvr] tulip, de2104x: fix typo: s/__sparc_/__sparc__/ Noticed by Doug Nazar (via David Miller). Signed-off-by: Jeff Garzik Signed-off-by: Adrian Bunk Commit: d2b0510e3c44c9dfdd1b9f0204abee40140464ae Author: Al Viro Wed, 04 Apr 2007 23:32:02 +0200 b44: src_desc->addr is little-endian Signed-off-by: Al Viro Signed-off-by: Adrian Bunk Commit: feb26509abe0672e6b56fa4c4765c0e62d4432c3 Author: Alan Cox Wed, 04 Apr 2007 21:34:22 +0200 ide-floppy: Fix unformatted media crash A ZIP or similar with unformatted media will cause crashes when attempts are made to read/write it in some cases. This is because bs_factor is zero and we divide by it causing an oops. As the size of a non-accessible/non-existant media is really a bit of a zen question it doesn't matter if non-existant media is 512 bytes per sector or zero. Setting it to 1 causes us to generate 512 bytes/sector accesses and error properly. Based on a fix found lurking in an ancient bugzilla entry since about 2004 (ugghhh) Signed-off-by: Alan Cox Signed-off-by: Adrian Bunk Commit: 5f4a9d1b7a413d6aac382c51692ac0df785068c5 Author: Patrick McHardy Tue, 03 Apr 2007 04:03:55 +0200 [IFB]: Fix crash on input device removal The input_device pointer is not refcounted, which means the device may disappear while packets are queued, causing a crash when ifb passes packets with a stale skb->dev pointer to netif_rx(). Fix by storing the interface index instead and do a lookup where neccessary. Signed-off-by: Patrick McHardy Signed-off-by: Adrian Bunk Commit: cceec5186fce242e095dc5e9496841df5d4133b9 Author: David S. Miller Tue, 03 Apr 2007 01:50:31 +0200 [VIDEO] ffb: Fix two DAC handling bugs. The determination of whether the DAC has inverted cursor logic is broken, import the version checks the X.org driver uses to fix this. Next, when we change the timing generator, borrow code from X.org that does 10 NOP reads of the timing generator register afterwards to make sure the video-enable transition occurs cleanly. Finally, use macros for the DAC registers and fields in order to provide documentation for the next person who reads this code. Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk