linux, branch v2.6.19.4

Linux 2.6.19.4

2007-02-20T06:31:57Z

[PATCH] Fix a free-wrong-pointer bug in nfs/acl server (CVE-2007-0772)

2007-02-20T06:30:55Z

Due to type confusion, when an nfsacl verison 2 'ACCESS' request finishes and tries to clean up, it calls fh_put on entiredly the wrong thing and this can cause an oops. Signed-off-by: Neil Brown Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Linux 2.6.19.3

2007-02-05T16:31:59Z

[PATCH] sched: fix cond_resched_softirq() offset

2007-02-05T16:31:45Z

Remove the __resched_legal() check: it is conceptually broken. The biggest problem it had is that it can mask buggy cond_resched() calls. A cond_resched() call is only legal if we are not in an atomic context, with two narrow exceptions: - if the system is booting - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set But __resched_legal() hid this and just silently returned whenever these primitives were called from invalid contexts. (Same goes for cond_resched_locked() and cond_resched_softirq()). Furthermore, the __legal_resched(0) call was buggy in that it caused unnecessarily long softirq latencies via cond_resched_softirq(). (which is only called from softirq-off sections, hence the code did nothing.) The fix is to resurrect the efficiency of the might_sleep checks and to only allow the narrow exceptions. Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [chrisw: backport to 2.6.19.2] Signed-off-by: Chris Wright

[PATCH] move_task_off_dead_cpu() should be called with disabled ints

2007-02-05T16:31:45Z

move_task_off_dead_cpu() requires interrupts to be disabled, while migrate_dead() calls it with enabled interrupts. Added appropriate comments to functions and added BUG_ON(!irqs_disabled()) into double_rq_lock() and double_lock_balance() which are the origin sources of such bugs. Signed-off-by: Kirill Korotaev Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] SUNRPC: Give cloned RPC clients their own rpc_pipefs directory

2007-02-05T16:31:45Z

This patch fixes a regression in 2.6.19 in which the use of multiple krb5 mounts against the same NFS server may result in an Oops on unmount. The Oops is due to the fact that multiple NFS krb5 clients may end up inadvertently sharing the same rpc_pipefs upcall pipe. The first client to 'umount' will unlink that shared pipe, causing an Oops. The solution is to give each client their own upcall pipe. This fix has been in mainline since 2.6.20-rc1. Signed-off-by: Trond Myklebust [chrisw: backport to 2.6.19.2] Signed-off-by: Chris Wright

[PATCH] NETFILTER: xt_connbytes: fix division by zero

2007-02-05T16:31:45Z

When the packet counter of a connection is zero a division by zero occurs in div64_64(). Fix that by using zero as average value, which is correct as long as the packet counter didn't overflow, at which point we have lost anyway. Additionally we're probably going to go back to 64 bit counters in 2.6.21. Based on patch from Jonas Berlin , with suggestions from KOVACS Krisztian . Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright

[PATCH] TCP: skb is unexpectedly freed.

2007-02-05T16:31:45Z

I encountered a kernel panic with my test program, which is a very simple IPv6 client-server program. The server side sets IPV6_RECVPKTINFO on a listening socket, and the client side just sends a message to the server. Then the kernel panic occurs on the server. (If you need the test program, please let me know. I can provide it.) This problem happens because a skb is forcibly freed in tcp_rcv_state_process(). When a socket in listening state(TCP_LISTEN) receives a syn packet, then tcp_v6_conn_request() will be called from tcp_rcv_state_process(). If the tcp_v6_conn_request() successfully returns, the skb would be discarded by __kfree_skb(). However, in case of a listening socket which was already set IPV6_RECVPKTINFO, an address of the skb will be stored in treq->pktopts and a ref count of the skb will be incremented in tcp_v6_conn_request(). But, even if the skb is still in use, the skb will be freed. Then someone still using the freed skb will cause the kernel panic. I suggest to use kfree_skb() instead of __kfree_skb(). Signed-off-by: Masayuki Nakagawa Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] TCP: Fix sorting of SACK blocks.

2007-02-05T16:31:45Z

The sorting of SACK blocks actually munges them rather than sort, causing the TCP stack to ignore some SACK information and breaking the assumption of ordered SACK blocks after sorting. The sort takes the data from a second buffer which isn't moved causing subsequent data moves to occur from the wrong location. The fix is to use a temporary buffer as a normal sort does. Signed-off-By: Baruch Even Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] TCP: rare bad TCP checksum with 2.6.19

2007-02-05T16:31:45Z

The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE" changed to unconditional copying of ip_summed field from collapsed skb. This patch reverts this change. The majority of substantial work including heavy testing and diagnosing by: Michael Tokarev Possible reasons pointed by: Herbert Xu and Patrick McHardy. Signed-off-by: Jarek Poplawski Acked-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Chris Wright