From: Greg Kroah-Hartman Date: Thu, 14 Mar 2013 20:55:54 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.0.70~25 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5c993ff4ca997453377be9689f0388cbf9eaa514;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: ext3-fix-format-string-issues.patch serial-8250_pci-add-support-for-another-kind-of-netmos-technology-pci-9835-multi-i-o-controller.patch signal-always-clear-sa_restorer-on-execve.patch tty-do-not-reset-master-s-packet-mode.patch tty-serial-fix-typo-arch_s5p6450.patch --- diff --git a/queue-3.4/ext3-fix-format-string-issues.patch b/queue-3.4/ext3-fix-format-string-issues.patch new file mode 100644 index 00000000000..bc34c334b4b --- /dev/null +++ b/queue-3.4/ext3-fix-format-string-issues.patch @@ -0,0 +1,48 @@ +From 8d0c2d10dd72c5292eda7a06231056a4c972e4cc Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Sat, 9 Mar 2013 15:28:44 +0100 +Subject: ext3: Fix format string issues + +From: Lars-Peter Clausen + +commit 8d0c2d10dd72c5292eda7a06231056a4c972e4cc upstream. + +ext3_msg() takes the printk prefix as the second parameter and the +format string as the third parameter. Two callers of ext3_msg omit the +prefix and pass the format string as the second parameter and the first +parameter to the format string as the third parameter. In both cases +this string comes from an arbitrary source. Which means the string may +contain format string characters, which will +lead to undefined and potentially harmful behavior. + +The issue was introduced in commit 4cf46b67eb("ext3: Unify log messages +in ext3") and is fixed by this patch. + +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext3/super.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/ext3/super.c ++++ b/fs/ext3/super.c +@@ -364,7 +364,7 @@ static struct block_device *ext3_blkdev_ + return bdev; + + fail: +- ext3_msg(sb, "error: failed to open journal device %s: %ld", ++ ext3_msg(sb, KERN_ERR, "error: failed to open journal device %s: %ld", + __bdevname(dev, b), PTR_ERR(bdev)); + + return NULL; +@@ -891,7 +891,7 @@ static ext3_fsblk_t get_sb_block(void ** + /*todo: use simple_strtoll with >32bit ext3 */ + sb_block = simple_strtoul(options, &options, 0); + if (*options && *options != ',') { +- ext3_msg(sb, "error: invalid sb specification: %s", ++ ext3_msg(sb, KERN_ERR, "error: invalid sb specification: %s", + (char *) *data); + return 1; + } diff --git a/queue-3.4/serial-8250_pci-add-support-for-another-kind-of-netmos-technology-pci-9835-multi-i-o-controller.patch b/queue-3.4/serial-8250_pci-add-support-for-another-kind-of-netmos-technology-pci-9835-multi-i-o-controller.patch new file mode 100644 index 00000000000..2b3c097c9d8 --- /dev/null +++ b/queue-3.4/serial-8250_pci-add-support-for-another-kind-of-netmos-technology-pci-9835-multi-i-o-controller.patch @@ -0,0 +1,41 @@ +From 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 Mon Sep 17 00:00:00 2001 +From: Wang YanQing +Date: Fri, 1 Mar 2013 11:47:20 +0800 +Subject: serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller + +From: Wang YanQing + +commit 8d2f8cd424ca0b99001f3ff4f5db87c4e525f366 upstream. + +01:08.0 Communication controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01) + Subsystem: Device [1000:0012] + Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- + Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/8250/8250_pci.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/tty/serial/8250/8250_pci.c ++++ b/drivers/tty/serial/8250/8250_pci.c +@@ -4086,6 +4086,10 @@ static struct pci_device_id serial_pci_t + PCI_VENDOR_ID_IBM, 0x0299, + 0, 0, pbn_b0_bt_2_115200 }, + ++ { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9835, ++ 0x1000, 0x0012, ++ 0, 0, pbn_b0_bt_2_115200 }, ++ + { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9901, + 0xA000, 0x1000, + 0, 0, pbn_b0_1_115200 }, diff --git a/queue-3.4/series b/queue-3.4/series index a5e6a5a17d5..35f136093ca 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -9,3 +9,8 @@ usb-serial-add-rigblaster-advantage-to-device-table.patch usb-storage-fix-huawei-mode-switching-regression.patch usb-ehci-don-t-check-dma-values-in-qh-overlays.patch staging-vt6656-fix-oops-on-resume-from-suspend.patch +signal-always-clear-sa_restorer-on-execve.patch +ext3-fix-format-string-issues.patch +serial-8250_pci-add-support-for-another-kind-of-netmos-technology-pci-9835-multi-i-o-controller.patch +tty-serial-fix-typo-arch_s5p6450.patch +tty-do-not-reset-master-s-packet-mode.patch diff --git a/queue-3.4/signal-always-clear-sa_restorer-on-execve.patch b/queue-3.4/signal-always-clear-sa_restorer-on-execve.patch new file mode 100644 index 00000000000..444e866944e --- /dev/null +++ b/queue-3.4/signal-always-clear-sa_restorer-on-execve.patch @@ -0,0 +1,69 @@ +From 2ca39528c01a933f6689cd6505ce65bd6d68a530 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Wed, 13 Mar 2013 14:59:33 -0700 +Subject: signal: always clear sa_restorer on execve + +From: Kees Cook + +commit 2ca39528c01a933f6689cd6505ce65bd6d68a530 upstream. + +When the new signal handlers are set up, the location of sa_restorer is +not cleared, leaking a parent process's address space location to +children. This allows for a potential bypass of the parent's ASLR by +examining the sa_restorer value returned when calling sigaction(). + +Based on what should be considered "secret" about addresses, it only +matters across the exec not the fork (since the VMAs haven't changed +until the exec). But since exec sets SIG_DFL and keeps sa_restorer, +this is where it should be fixed. + +Given the few uses of sa_restorer, a "set" function was not written +since this would be the only use. Instead, we use +__ARCH_HAS_SA_RESTORER, as already done in other places. + +Example of the leak before applying this patch: + + $ cat /proc/$$/maps + ... + 7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so + ... + $ ./leak + ... + 7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so + ... + 1 0 (nil) 0x7fb9f30b94a0 + 2 4000000 (nil) 0x7f278bcaa4a0 + 3 4000000 (nil) 0x7f278bcaa4a0 + 4 0 (nil) 0x7fb9f30b94a0 + ... + +[akpm@linux-foundation.org: use SA_RESTORER for backportability] +Signed-off-by: Kees Cook +Reported-by: Emese Revfy +Cc: Emese Revfy +Cc: PaX Team +Cc: Al Viro +Cc: Oleg Nesterov +Cc: "Eric W. Biederman" +Cc: Serge Hallyn +Cc: Julien Tinnes +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/signal.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/signal.c ++++ b/kernel/signal.c +@@ -482,6 +482,9 @@ flush_signal_handlers(struct task_struct + if (force_default || ka->sa.sa_handler != SIG_IGN) + ka->sa.sa_handler = SIG_DFL; + ka->sa.sa_flags = 0; ++#ifdef SA_RESTORER ++ ka->sa.sa_restorer = NULL; ++#endif + sigemptyset(&ka->sa.sa_mask); + ka++; + } diff --git a/queue-3.4/tty-do-not-reset-master-s-packet-mode.patch b/queue-3.4/tty-do-not-reset-master-s-packet-mode.patch new file mode 100644 index 00000000000..354f061a906 --- /dev/null +++ b/queue-3.4/tty-do-not-reset-master-s-packet-mode.patch @@ -0,0 +1,63 @@ +From b81273a132177edd806476b953f6afeb17b786d5 Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Tue, 15 Jan 2013 23:26:22 +0100 +Subject: TTY: do not reset master's packet mode + +From: Jiri Slaby + +commit b81273a132177edd806476b953f6afeb17b786d5 upstream. + +Now that login from util-linux is forced to drop all references to a +TTY which it wants to hangup (to reach reference count 1) we are +seeing issues with telnet. When login closes its last reference to the +slave PTY, it also resets packet mode on the *master* side. And we +have a race here. + +What telnet does is fork+exec of `login'. Then there are two +scenarios: +* `login' closes the slave TTY and resets thus master's packet mode, + but even now telnet properly sets the mode, or +* `telnetd' sets packet mode on the master, `login' closes the slave + TTY and resets master's packet mode. + +The former case is OK. However the latter happens in much more cases, +by the order of magnitude to be precise. So when one tries to login to +such a messed telnet setup, they see the following: +inux login: + ogin incorrect + +Note the missing first letters -- telnet thinks it is still in the +packet mode, so when it receives "linux login" from `login', it +considers "l" as the type of the packet and strips it. + +SuS does not mention how the implementation should behave. Both BSDs I +checked (Free and Net) do not reset the flag upon the last close. + +By this I am resurrecting an old bug, see References. We are hitting +it regularly now, i.e. with updated util-linux, ergo login. + +Here, I am changing a behavior introduced back in 2.1 times. It would +better have a long time testing before goes upstream. + +Signed-off-by: Jiri Slaby +Cc: Mauro Carvalho Chehab +Cc: Bryan Mason +References: https://lkml.org/lkml/2009/11/11/223 +References: https://bugzilla.redhat.com/show_bug.cgi?id=504703 +References: https://bugzilla.novell.com/show_bug.cgi?id=797042 +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/pty.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/tty/pty.c ++++ b/drivers/tty/pty.c +@@ -47,7 +47,6 @@ static void pty_close(struct tty_struct + tty->packet = 0; + if (!tty->link) + return; +- tty->link->packet = 0; + set_bit(TTY_OTHER_CLOSED, &tty->link->flags); + wake_up_interruptible(&tty->link->read_wait); + wake_up_interruptible(&tty->link->write_wait); diff --git a/queue-3.4/tty-serial-fix-typo-arch_s5p6450.patch b/queue-3.4/tty-serial-fix-typo-arch_s5p6450.patch new file mode 100644 index 00000000000..d41fa24ab57 --- /dev/null +++ b/queue-3.4/tty-serial-fix-typo-arch_s5p6450.patch @@ -0,0 +1,33 @@ +From 827aa0d36d486f359808c8fb931cf7a71011a09d Mon Sep 17 00:00:00 2001 +From: Paul Bolle +Date: Sat, 9 Mar 2013 23:16:44 +0100 +Subject: tty: serial: fix typo "ARCH_S5P6450" + +From: Paul Bolle + +commit 827aa0d36d486f359808c8fb931cf7a71011a09d upstream. + +This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at +commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART +serial support for S5P6450") - which added this typo - makes clear this +should be CPU_S5P6450. + +Signed-off-by: Paul Bolle +Acked-by: Kukjin Kim +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/Kconfig ++++ b/drivers/tty/serial/Kconfig +@@ -197,7 +197,7 @@ config SERIAL_SAMSUNG_UARTS_4 + config SERIAL_SAMSUNG_UARTS + int + depends on ARM && PLAT_SAMSUNG +- default 6 if ARCH_S5P6450 ++ default 6 if CPU_S5P6450 + default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416 + default 3 + help