linux, branch v2.6.20.5

Linux 2.6.20.5

2007-04-06T10:44:59Z

APPLETALK: Fix a remotely triggerable crash

2007-04-06T10:43:18Z

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: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

generic_serial: fix decoding of baud rate

2007-04-06T10:43:17Z

Commit d720bc4b8fc5d6d179ef094908d4fbb5e436ffad partially removed a private implementation of baud speed decoding. However it doesn't seem to be complete: after the speed is decoded, it is still being used as an index to a local speed table (array overrun, no doubt). This was found by Graham Murray who noticed it caused a 2.6.19 regression with the SX driver: https://bugs.gentoo.org/170554 Signed-off-by: Daniel Drake Acked-by: Alan Cox Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

libata: sata_mv: Fix 50xx irq mask

2007-04-06T10:43:17Z

[libata] sata_mv: Fix 50xx irq mask IRQ mask bits assumed a 60xx or newer generation chip, which is very wrong for the 50xx series. Luckily both generations shared the per-port interrupt mask bits, leaving only the "misc chip features" bits to be completely mismatched. Fix 50xx by ensuring we only program bits that exist. Cc: Chuck Ebbert Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: sata_mv: don't touch reserved bits in EDMA config register

2007-04-06T10:43:17Z

[libata] sata_mv: don't touch reserved bits in EDMA config register The code in mv_edma_cfg() reflected its 60xx origins, by doing things [slightly] incorrectly on the older 50xx and newer 6042/7042 chips. Clean up the EDMA configuration setup such that, each chip family carefully initializes its own EDMA setup. Cc: Chuck Ebbert Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata bugfix: HDIO_DRIVE_TASK

2007-04-06T10:43:17Z

libata bugfix: HDIO_DRIVE_TASK I was trying to use HDIO_DRIVE_TASK for something today, and discovered that the libata implementation does not copy over the upper four LBA bits from args[6]. This is serious, as any tools using this ioctl would have their commands applied to the wrong sectors on the drive, possibly resulting in disk corruption. Ideally, newer apps should use SG_IO/ATA_16 directly, avoiding this bug. But with libata poised to displace drivers/ide, better compatibility here is a must. This patch fixes libata to use the upper four LBA bits passed in from the ioctl. The original drivers/ide implementation copies over all bits except for the master/slave select bit. With this patch, libata will copy only the four high-order LBA bits, just in case there are assumptions elsewhere in libata (?). Signed-off-by: Mark Lord Cc: Chuck Ebbert Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: clear TF before IDENTIFYing

2007-04-06T10:43:17Z

libata: clear TF before IDENTIFYing Some devices chock if Feature is not clear when IDENTIFY is issued. Set ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE for IDENTIFY such that whole TF is cleared when reading ID data. Kudos to Art Haas for testing various futile patches over several months and Mark Lord for pointing out the fix. Signed-off-by: Tejun Heo Cc: Art Haas Cc: Mark Lord Cc: Chuck Ebbert Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

CRYPTO: api: scatterwalk_copychunks() fails to advance through scatterlist

2007-04-06T10:43:17Z

[CRYPTO] api: scatterwalk_copychunks() fails to advance through scatterlist In the loop in scatterwalk_copychunks(), if walk->offset is zero, then scatterwalk_pagedone rounds that up to the nearest page boundary: walk->offset += PAGE_SIZE - 1; walk->offset &= PAGE_MASK; which is a no-op in this case, so we don't advance to the next element of the scatterlist array: if (walk->offset >= walk->sg->offset + walk->sg->length) scatterwalk_start(walk, sg_next(walk->sg)); and we end up copying the same data twice. It appears that other callers of scatterwalk_{page}done first advance walk->offset, so I believe that's the correct thing to do here. This caused a bug in NFS when run with krb5p security, which would cause some writes to fail with permissions errors--for example, writes of less than 8 bytes (the des blocksize) at the start of a file. A git-bisect shows the bug was originally introduced by 5c64097aa0f6dc4f27718ef47ca9a12538d62860, first in 2.6.19-rc1. Cc: Chuck Ebbert Signed-off-by: J. Bruce Fields Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

CIFS: reset mode when client notices that ATTR_READONLY is no longer set

2007-04-06T10:43:17Z

[CIFS] reset mode when client notices that ATTR_READONLY is no longer set [: removed changelog part of patch] Cc: Chuck Ebbert Signed-off-by: Alan Tyso Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

CIFS: Allow reset of file to ATTR_NORMAL when archive bit not set

2007-04-06T10:43:16Z

[CIFS] Allow reset of file to ATTR_NORMAL when archive bit not set When a file had a dos attribute of 0x1 (readonly - but dos attribute of archive was not set) - doing chmod 0777 or equivalent would try to set a dos attribute of 0 (which some servers ignore) rather than ATTR_NORMAL (0x20) which most servers accept. Does not affect servers which support the CIFS Unix Extensions. [: removed changelog part of patch] Cc: Chuck Ebbert Acked-by: Prasad Potluri Acked-by: Shirish Pargaonkar Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman