--- /dev/null
+From e27759d7a333d1f25d628c4f7caf845c51be51c2 Mon Sep 17 00:00:00 2001
+From: Erez Zadok <ezk@cs.sunysb.edu>
+Date: Thu, 3 Dec 2009 13:35:27 -0500
+Subject: ecryptfs: initialize private persistent file before dereferencing pointer
+
+From: Erez Zadok <ezk@cs.sunysb.edu>
+
+commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream.
+
+Ecryptfs_open dereferences a pointer to the private lower file (the one
+stored in the ecryptfs inode), without checking if the pointer is NULL.
+Right afterward, it initializes that pointer if it is NULL. Swap order of
+statements to first initialize. Bug discovered by Duckjin Kang.
+
+Signed-off-by: Duckjin Kang <fromdj2k@gmail.com>
+Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
+Cc: Dustin Kirkland <kirkland@canonical.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ecryptfs/file.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/fs/ecryptfs/file.c
++++ b/fs/ecryptfs/file.c
+@@ -192,13 +192,6 @@ static int ecryptfs_open(struct inode *i
+ | ECRYPTFS_ENCRYPTED);
+ }
+ mutex_unlock(&crypt_stat->cs_mutex);
+- if ((ecryptfs_inode_to_private(inode)->lower_file->f_flags & O_RDONLY)
+- && !(file->f_flags & O_RDONLY)) {
+- rc = -EPERM;
+- printk(KERN_WARNING "%s: Lower persistent file is RO; eCryptfs "
+- "file must hence be opened RO\n", __func__);
+- goto out;
+- }
+ if (!ecryptfs_inode_to_private(inode)->lower_file) {
+ rc = ecryptfs_init_persistent_file(ecryptfs_dentry);
+ if (rc) {
+@@ -209,6 +202,13 @@ static int ecryptfs_open(struct inode *i
+ goto out;
+ }
+ }
++ if ((ecryptfs_inode_to_private(inode)->lower_file->f_flags & O_RDONLY)
++ && !(file->f_flags & O_RDONLY)) {
++ rc = -EPERM;
++ printk(KERN_WARNING "%s: Lower persistent file is RO; eCryptfs "
++ "file must hence be opened RO\n", __func__);
++ goto out;
++ }
+ ecryptfs_set_file_lower(
+ file, ecryptfs_inode_to_private(inode)->lower_file);
+ if (S_ISDIR(ecryptfs_dentry->d_inode->i_mode)) {
--- /dev/null
+From ece550f51ba175c14ec3ec047815927d7386ea1f Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <error27@gmail.com>
+Date: Tue, 19 Jan 2010 12:34:32 +0300
+Subject: ecryptfs: use after free
+
+From: Dan Carpenter <error27@gmail.com>
+
+commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream.
+
+The "full_alg_name" variable is used on a couple error paths, so we
+shouldn't free it until the end.
+
+Signed-off-by: Dan Carpenter <error27@gmail.com>
+Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ecryptfs/crypto.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/ecryptfs/crypto.c
++++ b/fs/ecryptfs/crypto.c
+@@ -1733,7 +1733,7 @@ ecryptfs_process_key_cipher(struct crypt
+ char *cipher_name, size_t *key_size)
+ {
+ char dummy_key[ECRYPTFS_MAX_KEY_BYTES];
+- char *full_alg_name;
++ char *full_alg_name = NULL;
+ int rc;
+
+ *key_tfm = NULL;
+@@ -1748,7 +1748,6 @@ ecryptfs_process_key_cipher(struct crypt
+ if (rc)
+ goto out;
+ *key_tfm = crypto_alloc_blkcipher(full_alg_name, 0, CRYPTO_ALG_ASYNC);
+- kfree(full_alg_name);
+ if (IS_ERR(*key_tfm)) {
+ rc = PTR_ERR(*key_tfm);
+ printk(KERN_ERR "Unable to allocate crypto cipher with name "
+@@ -1770,6 +1769,7 @@ ecryptfs_process_key_cipher(struct crypt
+ goto out;
+ }
+ out:
++ kfree(full_alg_name);
+ return rc;
+ }
+
edac-i5000_edac-critical-fix-panic-out-of-bounds.patch
megaraid_sas-remove-sysfs-poll_mode_io-world-writeable-permissions.patch
reiserfs-truncate-blocks-not-used-by-a-write.patch
+ecryptfs-initialize-private-persistent-file-before-dereferencing-pointer.patch
+ecryptfs-use-after-free.patch
+tty-fix-race-in-tty_fasync.patch
+usb-add-missing-delay-during-remote-wakeup.patch
+usb-ehci-fix-handling-of-unusual-interrupt-intervals.patch
+usb-ehci-uhci-fix-race-between-root-hub-suspend-and-port-resume.patch
--- /dev/null
+From 703625118069f9f8960d356676662d3db5a9d116 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@suse.de>
+Date: Thu, 17 Dec 2009 07:07:19 -0800
+Subject: tty: fix race in tty_fasync
+
+From: Greg Kroah-Hartman <gregkh@suse.de>
+
+commit 703625118069f9f8960d356676662d3db5a9d116 upstream.
+
+We need to keep the lock held over the call to __f_setown() to
+prevent a PID race.
+
+Thanks to Al Viro for pointing out the problem, and to Travis for
+making us look here in the first place.
+
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Al Viro <viro@ZenIV.linux.org.uk>
+Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Tavis Ormandy <taviso@google.com>
+Cc: Jeff Dike <jdike@addtoit.com>
+Cc: Julien Tinnes <jln@google.com>
+Cc: Matt Mackall <mpm@selenic.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/char/tty_io.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/tty_io.c
++++ b/drivers/char/tty_io.c
+@@ -2437,8 +2437,8 @@ static int tty_fasync(int fd, struct fil
+ pid = task_pid(current);
+ type = PIDTYPE_PID;
+ }
+- spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+ retval = __f_setown(filp, pid, type, 0);
++ spin_unlock_irqrestore(&tty->ctrl_lock, flags);
+ if (retval)
+ goto out;
+ } else {
--- /dev/null
+From 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 8 Jan 2010 11:18:38 -0500
+Subject: USB: add missing delay during remote wakeup
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 49d0f078f494b9d81e820a13dd8093a9bfb0b6b1 upstream.
+
+This patch (as1330) fixes a bug in khbud's handling of remote
+wakeups. When a device sends a remote-wakeup request, the parent hub
+(or the host controller driver, for directly attached devices) begins
+the resume sequence and notifies khubd when the sequence finishes. At
+this point the port's SUSPEND feature is automatically turned off.
+
+However the device needs an additional 10-ms resume-recovery time
+(TRSMRCY in the USB spec). Khubd does not wait for this delay if the
+SUSPEND feature is off, and as a result some devices fail to behave
+properly following a remote wakeup. This patch adds the missing
+delay to the remote-wakeup path.
+
+It also extends the resume-signalling delay used by ehci-hcd and
+uhci-hcd from 20 ms (the value in the spec) to 25 ms (the value we use
+for non-remote-wakeup resumes). The extra time appears to help some
+devices.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Cc: Rickard Bellini <rickard.bellini@ericsson.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/core/hub.c | 3 +++
+ drivers/usb/host/ehci-hcd.c | 5 +++--
+ drivers/usb/host/uhci-hub.c | 2 +-
+ 3 files changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -3015,6 +3015,9 @@ static void hub_events(void)
+ USB_PORT_FEAT_C_SUSPEND);
+ udev = hdev->children[i-1];
+ if (udev) {
++ /* TRSMRCY = 10 msec */
++ msleep(10);
++
+ usb_lock_device(udev);
+ ret = remote_wakeup(hdev->
+ children[i-1]);
+--- a/drivers/usb/host/ehci-hcd.c
++++ b/drivers/usb/host/ehci-hcd.c
+@@ -723,9 +723,10 @@ static irqreturn_t ehci_irq (struct usb_
+
+ /* start 20 msec resume signaling from this port,
+ * and make khubd collect PORT_STAT_C_SUSPEND to
+- * stop that signaling.
++ * stop that signaling. Use 5 ms extra for safety,
++ * like usb_port_resume() does.
+ */
+- ehci->reset_done [i] = jiffies + msecs_to_jiffies (20);
++ ehci->reset_done[i] = jiffies + msecs_to_jiffies(25);
+ ehci_dbg (ehci, "port %d remote wakeup\n", i + 1);
+ mod_timer(&hcd->rh_timer, ehci->reset_done[i]);
+ }
+--- a/drivers/usb/host/uhci-hub.c
++++ b/drivers/usb/host/uhci-hub.c
+@@ -167,7 +167,7 @@ static void uhci_check_ports(struct uhci
+ /* Port received a wakeup request */
+ set_bit(port, &uhci->resuming_ports);
+ uhci->ports_timeout = jiffies +
+- msecs_to_jiffies(20);
++ msecs_to_jiffies(25);
+
+ /* Make sure we see the port again
+ * after the resuming period is over. */
--- /dev/null
+From 1b9a38bfa6e664ff02511314f5586d711c83cc91 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 8 Jan 2010 11:17:55 -0500
+Subject: USB: EHCI: fix handling of unusual interrupt intervals
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 1b9a38bfa6e664ff02511314f5586d711c83cc91 upstream.
+
+This patch (as1320) fixes two problems related to interrupt-URB
+scheduling in ehci-hcd.
+
+ URBs with an interval of 2 or 4 microframes aren't handled.
+ For the time being, the patch reduces to interval to 1 uframe.
+
+ URBs are constrained to have an interval no larger than 1024
+ frames by usb_submit_urb(). But some EHCI controllers allow
+ use of a schedule as short as 256 frames; for these
+ controllers we may have to decrease the interval to the
+ actual schedule length.
+
+The second problem isn't very significant since few devices expose
+interrupt endpoints with an interval larger than 256 frames. But the
+first problem is critical; it will prevent the kernel from working
+with devices having interrupt intervals of 2 or 4 uframes.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Tested-by: Glynn Farrow <farrowg@sg.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/ehci-q.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/ehci-q.c
++++ b/drivers/usb/host/ehci-q.c
+@@ -748,9 +748,10 @@ qh_make (
+ * But interval 1 scheduling is simpler, and
+ * includes high bandwidth.
+ */
+- dbg ("intr period %d uframes, NYET!",
+- urb->interval);
+- goto done;
++ urb->interval = 1;
++ } else if (qh->period > ehci->periodic_size) {
++ qh->period = ehci->periodic_size;
++ urb->interval = qh->period << 3;
+ }
+ } else {
+ int think_time;
+@@ -773,6 +774,10 @@ qh_make (
+ usb_calc_bus_time (urb->dev->speed,
+ is_input, 0, max_packet (maxp)));
+ qh->period = urb->interval;
++ if (qh->period > ehci->periodic_size) {
++ qh->period = ehci->periodic_size;
++ urb->interval = qh->period;
++ }
+ }
+ }
+
--- /dev/null
+From cec3a53c7fe794237b582e8e77fc0e48465e65ee Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 8 Jan 2010 11:18:20 -0500
+Subject: USB: EHCI & UHCI: fix race between root-hub suspend and port resume
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit cec3a53c7fe794237b582e8e77fc0e48465e65ee upstream.
+
+This patch (as1321) fixes a problem with EHCI and UHCI root-hub
+suspends: If the suspend occurs while a port is trying to resume, the
+resume doesn't finish and simply gets lost. When remote wakeup is
+enabled, this is undesirable behavior.
+
+The patch checks first to see if any port resumes are in progress, and
+if they are then it fails the root-hub suspend with -EBUSY.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/ehci-hub.c | 20 +++++++++++++++++++-
+ drivers/usb/host/uhci-hcd.c | 15 ++++++++++++++-
+ 2 files changed, 33 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/host/ehci-hub.c
++++ b/drivers/usb/host/ehci-hub.c
+@@ -119,9 +119,26 @@ static int ehci_bus_suspend (struct usb_
+ del_timer_sync(&ehci->watchdog);
+ del_timer_sync(&ehci->iaa_watchdog);
+
+- port = HCS_N_PORTS (ehci->hcs_params);
+ spin_lock_irq (&ehci->lock);
+
++ /* Once the controller is stopped, port resumes that are already
++ * in progress won't complete. Hence if remote wakeup is enabled
++ * for the root hub and any ports are in the middle of a resume or
++ * remote wakeup, we must fail the suspend.
++ */
++ if (hcd->self.root_hub->do_remote_wakeup) {
++ port = HCS_N_PORTS(ehci->hcs_params);
++ while (port--) {
++ if (ehci->reset_done[port] != 0) {
++ spin_unlock_irq(&ehci->lock);
++ ehci_dbg(ehci, "suspend failed because "
++ "port %d is resuming\n",
++ port + 1);
++ return -EBUSY;
++ }
++ }
++ }
++
+ /* stop schedules, clean any completed work */
+ if (HC_IS_RUNNING(hcd->state)) {
+ ehci_quiesce (ehci);
+@@ -137,6 +154,7 @@ static int ehci_bus_suspend (struct usb_
+ */
+ ehci->bus_suspended = 0;
+ ehci->owned_ports = 0;
++ port = HCS_N_PORTS(ehci->hcs_params);
+ while (port--) {
+ u32 __iomem *reg = &ehci->regs->port_status [port];
+ u32 t1 = ehci_readl(ehci, reg) & ~PORT_RWC_BITS;
+--- a/drivers/usb/host/uhci-hcd.c
++++ b/drivers/usb/host/uhci-hcd.c
+@@ -750,7 +750,20 @@ static int uhci_rh_suspend(struct usb_hc
+ spin_lock_irq(&uhci->lock);
+ if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))
+ rc = -ESHUTDOWN;
+- else if (!uhci->dead)
++ else if (uhci->dead)
++ ; /* Dead controllers tell no tales */
++
++ /* Once the controller is stopped, port resumes that are already
++ * in progress won't complete. Hence if remote wakeup is enabled
++ * for the root hub and any ports are in the middle of a resume or
++ * remote wakeup, we must fail the suspend.
++ */
++ else if (hcd->self.root_hub->do_remote_wakeup &&
++ uhci->resuming_ports) {
++ dev_dbg(uhci_dev(uhci), "suspend failed because a port "
++ "is resuming\n");
++ rc = -EBUSY;
++ } else
+ suspend_rh(uhci, UHCI_RH_SUSPENDED);
+ spin_unlock_irq(&uhci->lock);
+ return rc;