3.0 patches

4 files changed, 164 insertions, 0 deletions

diff --git a/queue-3.0/series b/queue-3.0/series
index b6a7277d63..492484cf2f 100644
--- a/queue-3.0/series
+++ b/queue-3.0/series
@@ -189,3 +189,6 @@ vlan-reset-headers-on-accel-emulation-path.patch
 xfrm-perform-a-replay-check-after-return-from-async-codepaths.patch
 bridge-pseudo-header-required-for-the-checksum-of-icmpv6.patch
 bridge-fix-a-possible-use-after-free.patch
+zorro-defer-device_register-until-all-devices-have-been-identified.patch
+tpm-call-tpm_transmit-with-correct-size.patch
+tpm-zero-buffer-after-copying-to-userspace.patch
diff --git a/queue-3.0/tpm-call-tpm_transmit-with-correct-size.patch b/queue-3.0/tpm-call-tpm_transmit-with-correct-size.patch
new file mode 100644
index 0000000000..cc99a978bf
--- /dev/null
+++ b/queue-3.0/tpm-call-tpm_transmit-with-correct-size.patch
@@ -0,0 +1,43 @@
+From 6b07d30aca7e52f2881b8c8c20c8a2cd28e8b3d3 Mon Sep 17 00:00:00 2001
+From: Peter Huewe <huewe.external.infineon@googlemail.com>
+Date: Thu, 15 Sep 2011 14:37:43 -0300
+Subject: TPM: Call tpm_transmit with correct size
+
+From: Peter Huewe <huewe.external.infineon@googlemail.com>
+
+commit 6b07d30aca7e52f2881b8c8c20c8a2cd28e8b3d3 upstream.
+
+This patch changes the call of tpm_transmit by supplying the size of the
+userspace buffer instead of TPM_BUFSIZE.
+
+This got assigned CVE-2011-1161.
+
+[The first hunk didn't make sense given one could expect
+ way less data than TPM_BUFSIZE, so added tpm_transmit boundary
+ check over bufsiz instead
+ The last parameter of tpm_transmit() reflects the amount
+ of data expected from the device, and not the buffer size
+ being supplied to it. It isn't ideal to parse it directly,
+ so we just set it to the maximum the input buffer can handle
+ and let the userspace API to do such job.]
+
+Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
+Signed-off-by: James Morris <jmorris@namei.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/char/tpm/tpm.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/char/tpm/tpm.c
++++ b/drivers/char/tpm/tpm.c
+@@ -383,6 +383,9 @@ static ssize_t tpm_transmit(struct tpm_c
+ 	u32 count, ordinal;
+ 	unsigned long stop;
+ 
++	if (bufsiz > TPM_BUFSIZE)
++		bufsiz = TPM_BUFSIZE;
++
+ 	count = be32_to_cpu(*((__be32 *) (buf + 2)));
+ 	ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
+ 	if (count == 0)
diff --git a/queue-3.0/tpm-zero-buffer-after-copying-to-userspace.patch b/queue-3.0/tpm-zero-buffer-after-copying-to-userspace.patch
new file mode 100644
index 0000000000..486c8c9a3b
--- /dev/null
+++ b/queue-3.0/tpm-zero-buffer-after-copying-to-userspace.patch
@@ -0,0 +1,45 @@
+From 3321c07ae5068568cd61ac9f4ba749006a7185c9 Mon Sep 17 00:00:00 2001
+From: Peter Huewe <huewe.external.infineon@googlemail.com>
+Date: Thu, 15 Sep 2011 14:47:42 -0300
+Subject: TPM: Zero buffer after copying to userspace
+
+From: Peter Huewe <huewe.external.infineon@googlemail.com>
+
+commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 upstream.
+
+Since the buffer might contain security related data it might be a good idea to
+zero the buffer after we have copied it to userspace.
+
+This got assigned CVE-2011-1162.
+
+Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
+Signed-off-by: James Morris <jmorris@namei.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/char/tpm/tpm.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/char/tpm/tpm.c
++++ b/drivers/char/tpm/tpm.c
+@@ -1055,6 +1055,7 @@ ssize_t tpm_read(struct file *file, char
+ {
+ 	struct tpm_chip *chip = file->private_data;
+ 	ssize_t ret_size;
++	int rc;
+ 
+ 	del_singleshot_timer_sync(&chip->user_read_timer);
+ 	flush_work_sync(&chip->work);
+@@ -1065,8 +1066,11 @@ ssize_t tpm_read(struct file *file, char
+ 			ret_size = size;
+ 
+ 		mutex_lock(&chip->buffer_mutex);
+-		if (copy_to_user(buf, chip->data_buffer, ret_size))
++		rc = copy_to_user(buf, chip->data_buffer, ret_size);
++		memset(chip->data_buffer, 0, ret_size);
++		if (rc)
+ 			ret_size = -EFAULT;
++
+ 		mutex_unlock(&chip->buffer_mutex);
+ 	}
+ 
diff --git a/queue-3.0/zorro-defer-device_register-until-all-devices-have-been-identified.patch b/queue-3.0/zorro-defer-device_register-until-all-devices-have-been-identified.patch
new file mode 100644
index 0000000000..6aa4be9d80
--- /dev/null
+++ b/queue-3.0/zorro-defer-device_register-until-all-devices-have-been-identified.patch
@@ -0,0 +1,73 @@
+From a7f4d00a82feb5b311f765bf9522bc55bee0684f Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+Date: Thu, 22 Sep 2011 21:47:38 +0200
+Subject: zorro: Defer device_register() until all devices have been identified
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+
+commit a7f4d00a82feb5b311f765bf9522bc55bee0684f upstream.
+
+As the Amiga Zorro II address space is limited to 8.5 MiB and Zorro
+devices can contain only one BAR, several Amiga Zorro II expansion
+boards (mainly graphics cards) contain multiple Zorro devices: a small
+one for the control registers and one (or more) for the graphics memory.
+
+The conversion of cirrusfb to the new driver framework introduced a
+regression: the driver contains a zorro_driver for the first Zorro
+device, and uses the (old) zorro_find_device() call to find the second
+Zorro device.
+
+However, as the Zorro core calls device_register() as soon as a Zorro
+device is identified, it may not have identified the second Zorro device
+belonging to the same physical Zorro expansion card.  Hence cirrusfb
+could no longer find the second part of the Picasso II graphics card,
+causing a NULL pointer dereference.
+
+Defer the registration of Zorro devices with the driver framework until
+all Zorro devices have been identified to fix this.
+
+Note that the alternative solution (modifying cirrusfb to register a
+zorro_driver for all Zorro devices belonging to a graphics card, instead
+of only for the first one, and adding a synchronization mechanism to
+defer initialization until all have been found), is not an option, as on
+some cards one device may be optional (e.g.  the second bank of 2 MiB of
+graphics memory on the Picasso IV in Zorro II mode).
+
+Reported-by: Ingo Jürgensmann <ij@2011.bluespice.org>
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/zorro/zorro.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/zorro/zorro.c
++++ b/drivers/zorro/zorro.c
+@@ -148,10 +148,10 @@ static int __init amiga_zorro_probe(stru
+ 	}
+ 	platform_set_drvdata(pdev, bus);
+ 
+-	/* Register all devices */
+ 	pr_info("Zorro: Probing AutoConfig expansion devices: %u device%s\n",
+ 		 zorro_num_autocon, zorro_num_autocon == 1 ? "" : "s");
+ 
++	/* First identify all devices ... */
+ 	for (i = 0; i < zorro_num_autocon; i++) {
+ 		z = &zorro_autocon[i];
+ 		z->id = (z->rom.er_Manufacturer<<16) | (z->rom.er_Product<<8);
+@@ -172,6 +172,11 @@ static int __init amiga_zorro_probe(stru
+ 		dev_set_name(&z->dev, "%02x", i);
+ 		z->dev.parent = &bus->dev;
+ 		z->dev.bus = &zorro_bus_type;
++	}
++
++	/* ... then register them */
++	for (i = 0; i < zorro_num_autocon; i++) {
++		z = &zorro_autocon[i];
+ 		error = device_register(&z->dev);
+ 		if (error) {
+ 			dev_err(&bus->dev, "Error registering device %s\n",