From 6d7dbe55fc2f7903c93b1ce5facd24013ce7abc9 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 2 Mar 2009 15:46:36 -0800 Subject: [PATCH] .28 patches --- ...-fix-for-so_bsdcompat-gsopt-infoleak.patch | 35 ++++++++ ...heck-it-only-catches-false-positives.patch | 84 +++++++++++++++++++ queue-2.6.28/series | 4 + ...c64-fix-crashes-in-jbusmc_print_dimm.patch | 29 +++++++ ...ing-via-userspace-access-from-kernel.patch | 56 +++++++++++++ 5 files changed, 208 insertions(+) create mode 100644 queue-2.6.28/net-amend-the-fix-for-so_bsdcompat-gsopt-infoleak.patch create mode 100644 queue-2.6.28/net-kill-skb_truesize_check-it-only-catches-false-positives.patch create mode 100644 queue-2.6.28/series create mode 100644 queue-2.6.28/sparc64-fix-crashes-in-jbusmc_print_dimm.patch create mode 100644 queue-2.6.28/sparc64-fix-dax-handling-via-userspace-access-from-kernel.patch diff --git a/queue-2.6.28/net-amend-the-fix-for-so_bsdcompat-gsopt-infoleak.patch b/queue-2.6.28/net-amend-the-fix-for-so_bsdcompat-gsopt-infoleak.patch new file mode 100644 index 00000000000..079dbff18dd --- /dev/null +++ b/queue-2.6.28/net-amend-the-fix-for-so_bsdcompat-gsopt-infoleak.patch @@ -0,0 +1,35 @@ +From aca218f461aeb9f7ee9bd4978db2b67a889cf87f Mon Sep 17 00:00:00 2001 +From: Eugene Teo +Date: Mon, 23 Feb 2009 15:38:41 -0800 +Subject: net: amend the fix for SO_BSDCOMPAT gsopt infoleak + +From: Eugene Teo + +[ Upstream commit 50fee1dec5d71b8a14c1b82f2f42e16adc227f8b ] + +The fix for CVE-2009-0676 (upstream commit df0bca04) is incomplete. Note +that the same problem of leaking kernel memory will reappear if someone +on some architecture uses struct timeval with some internal padding (for +example tv_sec 64-bit and tv_usec 32-bit) --- then, you are going to +leak the padded bytes to userspace. + +Signed-off-by: Eugene Teo +Reported-by: Mikulas Patocka +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/core/sock.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/core/sock.c ++++ b/net/core/sock.c +@@ -696,7 +696,7 @@ int sock_getsockopt(struct socket *sock, + if (len < 0) + return -EINVAL; + +- v.val = 0; ++ memset(&v, 0, sizeof(v)); + + switch(optname) { + case SO_DEBUG: diff --git a/queue-2.6.28/net-kill-skb_truesize_check-it-only-catches-false-positives.patch b/queue-2.6.28/net-kill-skb_truesize_check-it-only-catches-false-positives.patch new file mode 100644 index 00000000000..5f205fc7e67 --- /dev/null +++ b/queue-2.6.28/net-kill-skb_truesize_check-it-only-catches-false-positives.patch @@ -0,0 +1,84 @@ +From be6562d8f13915451fd63a8718562f1db3dea36e Mon Sep 17 00:00:00 2001 +From: David S. Miller +Date: Tue, 17 Feb 2009 21:24:05 -0800 +Subject: net: Kill skb_truesize_check(), it only catches false-positives. + +From: David S. Miller + +[ Upstream commit 92a0acce186cde8ead56c6915d9479773673ea1a ] + +A long time ago we had bugs, primarily in TCP, where we would modify +skb->truesize (for TSO queue collapsing) in ways which would corrupt +the socket memory accounting. + +skb_truesize_check() was added in order to try and catch this error +more systematically. + +However this debugging check has morphed into a Frankenstein of sorts +and these days it does nothing other than catch false-positives. + +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/skbuff.h | 9 --------- + include/net/sock.h | 1 - + net/core/skbuff.c | 8 -------- + net/core/sock.c | 1 - + 4 files changed, 19 deletions(-) + +--- a/include/linux/skbuff.h ++++ b/include/linux/skbuff.h +@@ -411,15 +411,6 @@ extern void skb_over_panic(struct + void *here); + extern void skb_under_panic(struct sk_buff *skb, int len, + void *here); +-extern void skb_truesize_bug(struct sk_buff *skb); +- +-static inline void skb_truesize_check(struct sk_buff *skb) +-{ +- int len = sizeof(struct sk_buff) + skb->len; +- +- if (unlikely((int)skb->truesize < len)) +- skb_truesize_bug(skb); +-} + + extern int skb_append_datato_frags(struct sock *sk, struct sk_buff *skb, + int getfrag(void *from, char *to, int offset, +--- a/include/net/sock.h ++++ b/include/net/sock.h +@@ -784,7 +784,6 @@ static inline void sk_mem_uncharge(struc + + static inline void sk_wmem_free_skb(struct sock *sk, struct sk_buff *skb) + { +- skb_truesize_check(skb); + sock_set_flag(sk, SOCK_QUEUE_SHRUNK); + sk->sk_wmem_queued -= skb->truesize; + sk_mem_uncharge(sk, skb->truesize); +--- a/net/core/skbuff.c ++++ b/net/core/skbuff.c +@@ -143,14 +143,6 @@ void skb_under_panic(struct sk_buff *skb + BUG(); + } + +-void skb_truesize_bug(struct sk_buff *skb) +-{ +- WARN(net_ratelimit(), KERN_ERR "SKB BUG: Invalid truesize (%u) " +- "len=%u, sizeof(sk_buff)=%Zd\n", +- skb->truesize, skb->len, sizeof(struct sk_buff)); +-} +-EXPORT_SYMBOL(skb_truesize_bug); +- + /* Allocate a new skbuff. We do this ourselves so we can fill in a few + * 'private' fields and also do memory statistics to find all the + * [BEEP] leaks. +--- a/net/core/sock.c ++++ b/net/core/sock.c +@@ -1137,7 +1137,6 @@ void sock_rfree(struct sk_buff *skb) + { + struct sock *sk = skb->sk; + +- skb_truesize_check(skb); + atomic_sub(skb->truesize, &sk->sk_rmem_alloc); + sk_mem_uncharge(skb->sk, skb->truesize); + } diff --git a/queue-2.6.28/series b/queue-2.6.28/series new file mode 100644 index 00000000000..30b1a3f12ff --- /dev/null +++ b/queue-2.6.28/series @@ -0,0 +1,4 @@ +net-amend-the-fix-for-so_bsdcompat-gsopt-infoleak.patch +net-kill-skb_truesize_check-it-only-catches-false-positives.patch +sparc64-fix-crashes-in-jbusmc_print_dimm.patch +sparc64-fix-dax-handling-via-userspace-access-from-kernel.patch diff --git a/queue-2.6.28/sparc64-fix-crashes-in-jbusmc_print_dimm.patch b/queue-2.6.28/sparc64-fix-crashes-in-jbusmc_print_dimm.patch new file mode 100644 index 00000000000..6a495a67c22 --- /dev/null +++ b/queue-2.6.28/sparc64-fix-crashes-in-jbusmc_print_dimm.patch @@ -0,0 +1,29 @@ +From c58782f7cc112f93f95554d7a8ab05b1fdd92ae6 Mon Sep 17 00:00:00 2001 +From: David S. Miller +Date: Wed, 11 Feb 2009 00:54:07 -0800 +Subject: sparc64: Fix crashes in jbusmc_print_dimm() + +From: David S. Miller + +[ Upstream commit 1b0e235cc9bfae4bc0f5cd0cba929206fb0f6a64 ] + +Return was missing for the case where there is no dimm +info match. + +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + arch/sparc64/kernel/chmc.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/sparc64/kernel/chmc.c ++++ b/arch/sparc64/kernel/chmc.c +@@ -306,6 +306,7 @@ static int jbusmc_print_dimm(int syndrom + buf[1] = '?'; + buf[2] = '?'; + buf[3] = '\0'; ++ return 0; + } + p = dp->controller; + prop = &p->layout; diff --git a/queue-2.6.28/sparc64-fix-dax-handling-via-userspace-access-from-kernel.patch b/queue-2.6.28/sparc64-fix-dax-handling-via-userspace-access-from-kernel.patch new file mode 100644 index 00000000000..6c414714339 --- /dev/null +++ b/queue-2.6.28/sparc64-fix-dax-handling-via-userspace-access-from-kernel.patch @@ -0,0 +1,56 @@ +From 02c18518b706b8e53fd916befe6fab2bd12a5189 Mon Sep 17 00:00:00 2001 +From: David S. Miller +Date: Mon, 19 Jan 2009 22:56:51 -0800 +Subject: sparc64: Fix DAX handling via userspace access from kernel. + +From: David S. Miller + +[ Upstream commit fcd26f7ae2ea5889134e8b3d60a42ce8b993c95f ] + +If we do a userspace access from kernel mode, and get a +data access exception, we need to check the exception +table just like a normal fault does. + +The spitfire DAX handler was doing this, but such logic +was missing from the sun4v DAX code. + +Reported-by: Dennis Gilmore +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + arch/sparc64/kernel/traps.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +--- a/arch/sparc64/kernel/traps.c ++++ b/arch/sparc64/kernel/traps.c +@@ -1,6 +1,6 @@ + /* arch/sparc64/kernel/traps.c + * +- * Copyright (C) 1995,1997,2008 David S. Miller (davem@davemloft.net) ++ * Copyright (C) 1995,1997,2008,2009 David S. Miller (davem@davemloft.net) + * Copyright (C) 1997,1999,2000 Jakub Jelinek (jakub@redhat.com) + */ + +@@ -313,6 +313,21 @@ void sun4v_data_access_exception(struct + return; + + if (regs->tstate & TSTATE_PRIV) { ++ /* Test if this comes from uaccess places. */ ++ const struct exception_table_entry *entry; ++ ++ entry = search_exception_tables(regs->tpc); ++ if (entry) { ++ /* Ouch, somebody is trying VM hole tricks on us... */ ++#ifdef DEBUG_EXCEPTIONS ++ printk("Exception: PC<%016lx> faddr\n", regs->tpc); ++ printk("EX_TABLE: insn<%016lx> fixup<%016lx>\n", ++ regs->tpc, entry->fixup); ++#endif ++ regs->tpc = entry->fixup; ++ regs->tnpc = regs->tpc + 4; ++ return; ++ } + printk("sun4v_data_access_exception: ADDR[%016lx] " + "CTX[%04x] TYPE[%04x], going.\n", + addr, ctx, type); -- 2.47.3