--- /dev/null
+From 8d0c2d10dd72c5292eda7a06231056a4c972e4cc Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Sat, 9 Mar 2013 15:28:44 +0100
+Subject: ext3: Fix format string issues
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+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 <lars@metafoo.de>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext3/super.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/ext3/super.c
++++ b/fs/ext3/super.c
+@@ -371,7 +371,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;
+@@ -892,7 +892,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;
+ }
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
+tty-serial-fix-typo-arch_s5p6450.patch
+tty-do-not-reset-master-s-packet-mode.patch
--- /dev/null
+From 2ca39528c01a933f6689cd6505ce65bd6d68a530 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+Date: Wed, 13 Mar 2013 14:59:33 -0700
+Subject: signal: always clear sa_restorer on execve
+
+From: Kees Cook <keescook@chromium.org>
+
+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 <keescook@chromium.org>
+Reported-by: Emese Revfy <re.emese@gmail.com>
+Cc: Emese Revfy <re.emese@gmail.com>
+Cc: PaX Team <pageexec@freemail.hu>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: "Eric W. Biederman" <ebiederm@xmission.com>
+Cc: Serge Hallyn <serge.hallyn@canonical.com>
+Cc: Julien Tinnes <jln@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/signal.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -437,6 +437,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++;
+ }
--- /dev/null
+From b81273a132177edd806476b953f6afeb17b786d5 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Tue, 15 Jan 2013 23:26:22 +0100
+Subject: TTY: do not reset master's packet mode
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+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 <jslaby@suse.cz>
+Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
+Cc: Bryan Mason <bmason@redhat.com>
+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 <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/pty.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/tty/pty.c
++++ b/drivers/tty/pty.c
+@@ -49,7 +49,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);
--- /dev/null
+From 827aa0d36d486f359808c8fb931cf7a71011a09d Mon Sep 17 00:00:00 2001
+From: Paul Bolle <pebolle@tiscali.nl>
+Date: Sat, 9 Mar 2013 23:16:44 +0100
+Subject: tty: serial: fix typo "ARCH_S5P6450"
+
+From: Paul Bolle <pebolle@tiscali.nl>
+
+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 <pebolle@tiscali.nl>
+Acked-by: Kukjin Kim <kgene.kim@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/Kconfig
++++ b/drivers/tty/serial/Kconfig
+@@ -458,7 +458,7 @@ config SERIAL_SAMSUNG_UARTS
+ int
+ depends on ARM && PLAT_SAMSUNG
+ default 2 if ARCH_S3C2400
+- default 6 if ARCH_S5P6450
++ default 6 if CPU_S5P6450
+ default 4 if SERIAL_SAMSUNG_UARTS_4
+ default 3
+ help