From 40f7a8011f8e2fccacf95b3e6638f4965c917bd3 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 10 Feb 2009 10:43:20 -0800 Subject: [PATCH] .27 patches --- ...s-member-name-in-dynamic_irq_cleanup.patch | 40 +++++++++++++ ...er-socket-race-during-accept-peeloff.patch | 59 +++++++++++++++++++ queue-2.6.27/series | 2 + 3 files changed, 101 insertions(+) create mode 100644 queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch create mode 100644 queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch diff --git a/queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch b/queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch new file mode 100644 index 00000000000..321b5e2a92b --- /dev/null +++ b/queue-2.6.27/genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch @@ -0,0 +1,40 @@ +From b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 Mon Sep 17 00:00:00 2001 +From: Dean Nelson +Date: Sat, 18 Oct 2008 16:06:56 -0700 +Subject: genirq: NULL struct irq_desc's member 'name' in dynamic_irq_cleanup() + +From: Dean Nelson + +commit b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 upstream. + +If the member 'name' of the irq_desc structure happens to point to a +character string that is resident within a kernel module, problems ensue +if that module is rmmod'd (at which time dynamic_irq_cleanup() is called) +and then later show_interrupts() is called by someone. + +It is also not a good thing if the character string resided in kmalloc'd +space that has been kfree'd (after having called dynamic_irq_cleanup()). +dynamic_irq_cleanup() fails to NULL the 'name' member and +show_interrupts() references it on a few architectures (like h8300, sh and +x86). + +Signed-off-by: Dean Nelson +Signed-off-by: Ingo Molnar +Signed-off-by: Andrew Morton +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/chip.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/kernel/irq/chip.c ++++ b/kernel/irq/chip.c +@@ -78,6 +78,7 @@ void dynamic_irq_cleanup(unsigned int ir + desc->chip_data = NULL; + desc->handle_irq = handle_bad_irq; + desc->chip = &no_irq_chip; ++ desc->name = NULL; + spin_unlock_irqrestore(&desc->lock, flags); + } + diff --git a/queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch b/queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch new file mode 100644 index 00000000000..9ad4d4bf0e2 --- /dev/null +++ b/queue-2.6.27/sctp-fix-another-socket-race-during-accept-peeloff.patch @@ -0,0 +1,59 @@ +From ae53b5bd77719fed58086c5be60ce4f22bffe1c6 Mon Sep 17 00:00:00 2001 +From: Vlad Yasevich +Date: Thu, 22 Jan 2009 14:53:23 -0800 +Subject: sctp: Fix another socket race during accept/peeloff + +From: Vlad Yasevich + +commit ae53b5bd77719fed58086c5be60ce4f22bffe1c6 upstream. + +There is a race between sctp_rcv() and sctp_accept() where we +have moved the association from the listening socket to the +accepted socket, but sctp_rcv() processing cached the old +socket and continues to use it. + +The easy solution is to check for the socket mismatch once we've +grabed the socket lock. If we hit a mis-match, that means +that were are currently holding the lock on the listening socket, +but the association is refrencing a newly accepted socket. We need +to drop the lock on the old socket and grab the lock on the new one. + +A more proper solution might be to create accepted sockets when +the new association is established, similar to TCP. That would +eliminate the race for 1-to-1 style sockets, but it would still +existing for 1-to-many sockets where a user wished to peeloff an +association. For now, we'll live with this easy solution as +it addresses the problem. + +Reported-by: Michal Hocko +Reported-by: Karsten Keil +Signed-off-by: Vlad Yasevich +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/sctp/input.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/net/sctp/input.c ++++ b/net/sctp/input.c +@@ -249,6 +249,19 @@ int sctp_rcv(struct sk_buff *skb) + */ + sctp_bh_lock_sock(sk); + ++ if (sk != rcvr->sk) { ++ /* Our cached sk is different from the rcvr->sk. This is ++ * because migrate()/accept() may have moved the association ++ * to a new socket and released all the sockets. So now we ++ * are holding a lock on the old socket while the user may ++ * be doing something with the new socket. Switch our veiw ++ * of the current sk. ++ */ ++ sctp_bh_unlock_sock(sk); ++ sk = rcvr->sk; ++ sctp_bh_lock_sock(sk); ++ } ++ + if (sock_owned_by_user(sk)) { + SCTP_INC_STATS_BH(SCTP_MIB_IN_PKT_BACKLOG); + sctp_add_backlog(sk, skb); diff --git a/queue-2.6.27/series b/queue-2.6.27/series index 0613c7f36b3..64a16240abe 100644 --- a/queue-2.6.27/series +++ b/queue-2.6.27/series @@ -52,3 +52,5 @@ usb-new-id-for-ti_usb_3410_5052-driver.patch usb-option-new-mobile-broadband-modems-to-be-supported.patch usb-two-more-usb-ids-for-ti_usb_3410_5052.patch usb-usb-storage-add-pentax-to-the-bad-vendor-list.patch +sctp-fix-another-socket-race-during-accept-peeloff.patch +genirq-null-struct-irq_desc-s-member-name-in-dynamic_irq_cleanup.patch -- 2.47.3