32 patches

added patches:
	ecryptfs-extend-array-bounds-for-all-filename-chars.patch
	i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch
	pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch

4 files changed, 154 insertions, 0 deletions

diff --git a/queue-2.6.32/ecryptfs-extend-array-bounds-for-all-filename-chars.patch b/queue-2.6.32/ecryptfs-extend-array-bounds-for-all-filename-chars.patch
new file mode 100644
index 0000000..96c187f
--- /dev/null
+++ b/queue-2.6.32/ecryptfs-extend-array-bounds-for-all-filename-chars.patch
@@ -0,0 +1,56 @@
+From 0f751e641a71157aa584c2a2e22fda52b52b8a56 Mon Sep 17 00:00:00 2001
+From: Tyler Hicks <tyhicks@canonical.com>
+Date: Wed, 23 Nov 2011 11:31:24 -0600
+Subject: eCryptfs: Extend array bounds for all filename chars
+
+From: Tyler Hicks <tyhicks@canonical.com>
+
+commit 0f751e641a71157aa584c2a2e22fda52b52b8a56 upstream.
+
+From mhalcrow's original commit message:
+
+    Characters with ASCII values greater than the size of
+    filename_rev_map[] are valid filename characters.
+    ecryptfs_decode_from_filename() will access kernel memory beyond
+    that array, and ecryptfs_parse_tag_70_packet() will then decrypt
+    those characters. The attacker, using the FNEK of the crafted file,
+    can then re-encrypt the characters to reveal the kernel memory past
+    the end of the filename_rev_map[] array. I expect low security
+    impact since this array is statically allocated in the text area,
+    and the amount of memory past the array that is accessible is
+    limited by the largest possible ASCII filename character.
+
+This patch solves the issue reported by mhalcrow but with an
+implementation suggested by Linus to simply extend the length of
+filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
+0x00, which is how invalid characters less than 0x7A were previously
+being handled.
+
+Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
+Reported-by: Michael Halcrow <mhalcrow@google.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
+@@ -1934,7 +1934,7 @@ static unsigned char *portable_filename_
+ 
+ /* We could either offset on every reverse map or just pad some 0x00's
+  * at the front here */
+-static const unsigned char filename_rev_map[] = {
++static const unsigned char filename_rev_map[256] = {
+ 	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 7 */
+ 	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 15 */
+ 	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 23 */
+@@ -1950,7 +1950,7 @@ static const unsigned char filename_rev_
+ 	0x00, 0x26, 0x27, 0x28, 0x29, 0x2A, 0x2B, 0x2C, /* 103 */
+ 	0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32, 0x33, 0x34, /* 111 */
+ 	0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C, /* 119 */
+-	0x3D, 0x3E, 0x3F
++	0x3D, 0x3E, 0x3F /* 123 - 255 initialized to 0x00 */
+ };
+ 
+ /**
diff --git a/queue-2.6.32/i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch b/queue-2.6.32/i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch
new file mode 100644
index 0000000..134bb04
--- /dev/null
+++ b/queue-2.6.32/i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch
@@ -0,0 +1,41 @@
+From cc6bcf7d2ec2234e7b41770185e4dc826390185e Mon Sep 17 00:00:00 2001
+From: "Jeffrey (Sheng-Hui) Chu" <jeffchu@broadcom.com>
+Date: Wed, 23 Nov 2011 11:33:07 +0100
+Subject: i2c-algo-bit: Generate correct i2c address sequence for 10-bit target
+
+From: "Jeffrey (Sheng-Hui) Chu" <jeffchu@broadcom.com>
+
+commit cc6bcf7d2ec2234e7b41770185e4dc826390185e upstream.
+
+The wrong bits were put on the wire, fix that.
+
+This fixes kernel bug #42562.
+
+Signed-off-by: Sheng-Hui J. Chu <jeffchu@broadcom.com>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/i2c/algos/i2c-algo-bit.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/algos/i2c-algo-bit.c
++++ b/drivers/i2c/algos/i2c-algo-bit.c
+@@ -471,7 +471,7 @@ static int bit_doAddress(struct i2c_adap
+ 
+ 	if (flags & I2C_M_TEN) {
+ 		/* a ten bit address */
+-		addr = 0xf0 | ((msg->addr >> 7) & 0x03);
++		addr = 0xf0 | ((msg->addr >> 7) & 0x06);
+ 		bit_dbg(2, &i2c_adap->dev, "addr0: %d\n", addr);
+ 		/* try extended address code...*/
+ 		ret = try_address(i2c_adap, addr, retries);
+@@ -481,7 +481,7 @@ static int bit_doAddress(struct i2c_adap
+ 			return -EREMOTEIO;
+ 		}
+ 		/* the remaining 8 bit address */
+-		ret = i2c_outb(i2c_adap, msg->addr & 0x7f);
++		ret = i2c_outb(i2c_adap, msg->addr & 0xff);
+ 		if ((ret != 1) && !nak_ok) {
+ 			/* the chip did not ack / xmission error occurred */
+ 			dev_err(&i2c_adap->dev, "died at 2nd address code\n");
diff --git a/queue-2.6.32/pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch b/queue-2.6.32/pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch
new file mode 100644
index 0000000..c474f87
--- /dev/null
+++ b/queue-2.6.32/pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch
@@ -0,0 +1,54 @@
+From 4cac2eb158c6da0c761689345c6cc5df788a6292 Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Tue, 23 Aug 2011 10:16:43 -0600
+Subject: PCI hotplug: shpchp: don't blindly claim non-AMD 0x7450 device IDs
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 4cac2eb158c6da0c761689345c6cc5df788a6292 upstream.
+
+Previously we claimed device ID 0x7450, regardless of the vendor, which is
+clearly wrong.  Now we'll claim that device ID only for AMD.
+
+I suspect this was just a typo in the original code, but it's possible this
+change will break shpchp on non-7450 AMD bridges.  If so, we'll have to fix
+them as we find them.
+
+Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
+Reported-by: Ralf Jung <ralfjung-e@gmx.de>
+Cc: Joerg Roedel <joerg.roedel@amd.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/hotplug/shpchp_core.c |    4 ++--
+ drivers/pci/hotplug/shpchp_hpc.c  |    4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/pci/hotplug/shpchp_core.c
++++ b/drivers/pci/hotplug/shpchp_core.c
+@@ -312,8 +312,8 @@ static int get_cur_bus_speed (struct hot
+ 
+ static int is_shpc_capable(struct pci_dev *dev)
+ {
+-	if ((dev->vendor == PCI_VENDOR_ID_AMD) || (dev->device ==
+-						PCI_DEVICE_ID_AMD_GOLAM_7450))
++	if (dev->vendor == PCI_VENDOR_ID_AMD &&
++	    dev->device == PCI_DEVICE_ID_AMD_GOLAM_7450)
+ 		return 1;
+ 	if (!pci_find_capability(dev, PCI_CAP_ID_SHPC))
+ 		return 0;
+--- a/drivers/pci/hotplug/shpchp_hpc.c
++++ b/drivers/pci/hotplug/shpchp_hpc.c
+@@ -951,8 +951,8 @@ int shpc_init(struct controller *ctrl, s
+ 	ctrl->pci_dev = pdev;  /* pci_dev of the P2P bridge */
+ 	ctrl_dbg(ctrl, "Hotplug Controller:\n");
+ 
+-	if ((pdev->vendor == PCI_VENDOR_ID_AMD) || (pdev->device ==
+-				PCI_DEVICE_ID_AMD_GOLAM_7450)) {
++	if (pdev->vendor == PCI_VENDOR_ID_AMD &&
++	    pdev->device == PCI_DEVICE_ID_AMD_GOLAM_7450) {
+ 		/* amd shpc driver doesn't use Base Offset; assume 0 */
+ 		ctrl->mmio_base = pci_resource_start(pdev, 0);
+ 		ctrl->mmio_size = pci_resource_len(pdev, 0);
diff --git a/queue-2.6.32/series b/queue-2.6.32/series
new file mode 100644
index 0000000..c5c7bd4
--- /dev/null
+++ b/queue-2.6.32/series
@@ -0,0 +1,3 @@
+i2c-algo-bit-generate-correct-i2c-address-sequence-for-10-bit-target.patch
+ecryptfs-extend-array-bounds-for-all-filename-chars.patch
+pci-hotplug-shpchp-don-t-blindly-claim-non-amd-0x7450-device-ids.patch