user/sven/linux.git, branch v2.6.20.2

Linux 2.6.20.2

2007-03-09T18:58:04Z

IPV6: Handle np->opt being NULL in ipv6_getsockopt_sticky() [CVE-2007-1000]

2007-03-09T18:50:33Z

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8134 Signed-off-by: David S. Miller Signed-off-by: Chris Wright

x86-64: survive having no irq mapping for a vector

2007-03-09T18:50:33Z

Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by: Eric W. Biederman Signed-off-by: Andi Kleen Cc: "Luigi Genoni" Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

Fix buffer overflow in Omnikey CardMan 4040 driver (CVE-2007-0005)

2007-03-09T18:50:32Z

Based on a patch from Don Howard When calling write() with a buffer larger than 512 bytes, the driver's write buffer overflows, allowing to overwrite the EIP and execute arbitrary code with kernel privileges. In read(), there exists a similar problem, but coming from the device. A malicous or buggy device sending more than 512 bytes can overflow of the driver's read buffer, with the same effects as above. Signed-off-by: Marcel Holtmann Signed-off-by: Harald Welte Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

TCP: Fix minisock tcp_create_openreq_child() typo.

2007-03-09T18:50:32Z

On 2/28/07, KOVACS Krisztian wrote: > > Hi, > > While reading TCP minisock code I've found this suspiciously looking > code fragment: > > - 8< - > struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb) > { > struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC); > > if (newsk != NULL) { > const struct inet_request_sock *ireq = inet_rsk(req); > struct tcp_request_sock *treq = tcp_rsk(req); > struct inet_connection_sock *newicsk = inet_csk(sk); > struct tcp_sock *newtp; > - 8< - > > The above code initializes newicsk to inet_csk(sk), isn't that supposed > to be inet_csk(newsk)? As far as I can tell this might leave > icsk_ack.last_seg_size zero even if we do have received data. Good catch! David, please apply the attached patch. Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Signed-off-by: Chris Wright

gfs2: fix locking mistake

2007-03-09T18:50:32Z

Fix a locking mistake in the quota code, we do a mutex_lock instead of a mutex_unlock. Signed-off-by: Josef Whiter Cc: Steven Whitehouse Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

ATA: convert GSI to irq on ia64

2007-03-09T18:50:32Z

If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed irq number. On ia64 platform, such numbers are GSI and should be converted to irq vector. Signed-off-by: Zhang Yanmin Cc: Jeff Garzik Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

pktcdvd: Correctly set cmd_len field in pkt_generic_packet

2007-03-09T18:50:31Z

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7810 - a silly copy-paste bug introduced by the latest change. Signed-off-by: Gerhard Dirschl Cc: Peter Osterlund Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

video/aty/mach64_ct.c: fix bogus delay loop

2007-03-09T18:50:31Z

CT based mach64 cards were reported to hang on sparc64 boxes when compiled with gcc-4.1.x and later. Looking at this piece of code, it's no surprise. A critical delay was implemented as an empty for() loop, and gcc 4.0.x and previous did not optimize it away, so we did get a delay. But gcc-4.1.x and later can optimize it away, and we get crashes. Use a real udelay() to fix this. Fix verified on SunBlade100. Signed-off-by: David S. Miller Cc: Andrew Morton Cc: "Antonino A. Daplas" Signed-off-by: Linus Torvalds

revert "drivers/net/tulip/dmfe: support basic carrier detection"

2007-03-09T18:50:31Z

Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8. Thomas Bachler reports: Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe: support basic carrier detection) breaks networking on my Davicom DM9009. ethtool always reports there is no link. tcpdump shows incoming packets, but TX is disabled. Reverting the above patch fixes the problem. Cc: Samuel Thibault Cc: Jeff Garzik Cc: Valerie Henson Cc: Thomas Bachler Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman