Commit: ba9cf57280307887879136d0d263e6ae91ac2635 Author: Adrian Bunk Tue, 07 Nov 2006 14:31:00 +0100 Linux 2.6.16.31 Commit: afaa018cefb6af63befef1df7d8febaae904434f Author: Adrian Bunk Sun, 05 Nov 2006 09:48:22 +0100 Linux 2.6.16.31-rc1 Commit: 0ddfcc96928145d6a6425fdd26dad6abfe7f891d Author: Patrick McHardy Sun, 05 Nov 2006 09:04:23 +0100 [NETFILTER]: Fix ip6_tables extension header bypass bug (CVE-2006-4572) As reported by Mark Dowd , ip6_tables is susceptible to a fragmentation attack causing false negatives on extension header matches. When extension headers occur in the non-first fragment after the fragment header (possibly with an incorrect nexthdr value in the fragment header) a rule looking for this extension header will never match. Drop fragments that are at offset 0 and don't contain the final protocol header regardless of the ruleset, since this should not happen normally. Since all extension headers are before the protocol header this makes sure an extension header is either not present or in the first fragment, where we can properly parse it. With help from Yasuyuki KOZAKAI . Signed-off-by: Patrick McHardy Signed-off-by: Adrian Bunk Commit: 6ac62be885810e1f8390f0c3b9d3ee451d3d3f19 Author: Patrick McHardy Sun, 05 Nov 2006 09:03:48 +0100 [NETFILTER]: Fix ip6_tables protocol bypass bug (CVE-2006-4572) As reported by Mark Dowd , ip6_tables is susceptible to a fragmentation attack causing false negatives on protocol matches. When the protocol header doesn't follow the fragment header immediately, the fragment header contains the protocol number of the next extension header. When the extension header and the protocol header are sent in a second fragment a rule like "ip6tables .. -p udp -j DROP" will never match. Drop fragments that are at offset 0 and don't contain the final protocol header regardless of the ruleset, since this should not happen normally. With help from Yasuyuki KOZAKAI . Signed-off-by: Patrick McHardy Signed-off-by: Adrian Bunk Commit: 0ac0a20823b92bf2bd39aa83c59c247b41ba3e44 Author: Neil Brown Sun, 05 Nov 2006 09:03:18 +0100 knfsd: Fix race that can disable NFS server. This is a long standing bug that seems to have only recently become apparent, presumably due to increasing use of NFS over TCP - many distros seem to be making it the default. The SK_CONN bit gets set when a listening socket may be ready for an accept, just as SK_DATA is set when data may be available. It is entirely possible for svc_tcp_accept to be called with neither of these set. It doesn't happen often but there is a small race in svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the spin_lock. They could be cleared immediately after the test and before the lock is gained. This normally shouldn't be a problem. The sockets are non-blocking so trying to read() or accept() when ther is nothing to do is not a problem. However: svc_tcp_recvfrom makes the decision "Should I accept() or should I read()" based on whether SK_CONN is set or not. This usually works but is not safe. The decision should be based on whether it is a TCP_LISTEN socket or a TCP_CONNECTED socket. Signed-off-by: Neil Brown Signed-off-by: Adrian Bunk Commit: fe8187b80c7b4fee6fd5dfb0d68891230ae59dcb Author: Thomas Gleixner Sun, 05 Nov 2006 09:02:46 +0100 posix-cpu-timers: prevent signal delivery starvation The integer divisions in the timer accounting code can round the result down to 0. Adding 0 is without effect and the signal delivery stops. Clamp the division result to minimum 1 to avoid this. Problem was reported by Seongbae Park , who provided also an inital patch. Roland sayeth: I have had some more time to think about the problem, and to reproduce it using Toyo's test case. For the record, if my understanding of the problem is correct, this happens only in one very particular case. First, the expiry time has to be so soon that in cputime_t units (usually 1s/HZ ticks) it's < nthreads so the division yields zero. Second, it only affects each thread that is so new that its CPU time accumulation is zero so now+0 is still zero and ->it_*_expires winds up staying zero. For the VIRT and PROF clocks when cputime_t is tick granularity (or the SCHED clock on configurations where sched_clock's value only advances on clock ticks), this is not hard to arrange with new threads starting up and blocking before they accumulate a whole tick of CPU time. That's what happens in Toyo's test case. Note that in general it is fine for that division to round down to zero, and set each thread's expiry time to its "now" time. The problem only arises with thread's whose "now" value is still zero, so that now+0 winds up 0 and is interpreted as "not set" instead of ">= now". So it would be a sufficient and more precise fix to just use max(ticks, 1) inside the loop when setting each it_*_expires value. But, it does no harm to round the division up to one and always advance every thread's expiry time. If the thread didn't already fire timers for the expiry time of "now", there is no expectation that it will do so before the next tick anyway. So I followed Thomas's patch in lifting the max out of the loops. This patch also covers the reload cases, which are harder to write a test for (and I didn't try). I've tested it with Toyo's case and it fixes that. [toyoa@mvista.com: fix: min_t -> max_t] Signed-off-by: Thomas Gleixner Signed-off-by: Roland McGrath Signed-off-by: Andrew Morton Signed-off-by: Adrian Bunk Commit: d1ce361a6c0115e2ef500e9e7dfe77763d287fcd Author: James Morris Sun, 05 Nov 2006 09:00:45 +0100 [IPV6]: fix lockup via /proc/net/ip6_flowlabel (CVE-2006-5619) There's a bug in the seqfile handling for /proc/net/ip6_flowlabel, where, after finding a flowlabel, the code will loop forever not finding any further flowlabels, first traversing the rest of the hash bucket then just looping. This patch fixes the problem by breaking after the hash bucket has been traversed. Note that this bug can cause lockups and oopses, and is trivially invoked by an unpriveleged user. Signed-off-by: James Morris Signed-off-by: David S. Miller Signed-off-by: Adrian Bunk Commit: e4943436e258e9f993be30d7ab41f7202f8adbf7 Author: Shaohua Li Sun, 05 Nov 2006 08:23:24 +0100 ACPI: enable SMP C-states on x86_64 http://bugzilla.kernel.org/show_bug.cgi?id=5653 Signed-off-by: Shaohua Li Signed-off-by: Len Brown Signed-off-by: Adrian Bunk Commit: c6cc8f7cac64400c74460157171daee80d00638c Author: Al Viro Sun, 05 Nov 2006 08:15:37 +0100 fix RARP ic_servaddr breakage memcpy 4 bytes to address of auto unsigned long variable followed by comparison with u32 is a bloody bad idea. Signed-off-by: Al Viro Signed-off-by: Adrian Bunk Commit: e77b34960d3e48f4e5d4aa2cdb737f618d3834b7 Author: Martin Schwidefsky Sun, 05 Nov 2006 08:03:01 +0100 [S390] fix user readable uninitialised kernel memory, take 2. The previous patch to correct the copy_from_user padding is quite broken. The execute instruction needs to be done via the register %r4, not via %r2 and 31 bit doesn't know the instructions lgr and ahji. Signed-off-by: Martin Schwidefsky Signed-off-by: Adrian Bunk Commit: dfa2e9e76edadc584a0da6966aa081527dad1372 Author: Martin Schwidefsky Sun, 05 Nov 2006 08:01:53 +0100 [S390] fix user readable uninitialised kernel memory (CVE-2006-5174) A user space program can read uninitialised kernel memory by appending to a file from a bad address and then reading the result back. The cause is the copy_from_user function that does not clear the remaining bytes of the kernel buffer after it got a fault on the user space address. Signed-off-by: Martin Schwidefsky Signed-off-by: Adrian Bunk