This is a note to let you know that I've just added the patch titled
tpm: Propagate error from tpm_transmit to fix a timeout hang
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
tpm-propagate-error-from-tpm_transmit-to-fix-a-timeout-hang.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From abce9ac292e13da367bbd22c1f7669f988d931ac Mon Sep 17 00:00:00 2001
From: Peter Huewe <[email protected]>
Date: Thu, 27 Sep 2012 16:09:33 +0200
Subject: tpm: Propagate error from tpm_transmit to fix a timeout hang
From: Peter Huewe <[email protected]>
commit abce9ac292e13da367bbd22c1f7669f988d931ac upstream.
tpm_write calls tpm_transmit without checking the return value and
assigns the return value unconditionally to chip->pending_data, even if
it's an error value.
This causes three bugs.
So if we write to /dev/tpm0 with a tpm_param_size bigger than
TPM_BUFSIZE=0x1000 (e.g. 0x100a)
and a bufsize also bigger than TPM_BUFSIZE (e.g. 0x100a)
tpm_transmit returns -E2BIG which is assigned to chip->pending_data as
-7, but tpm_write returns that TPM_BUFSIZE bytes have been successfully
been written to the TPM, altough this is not true (bug #1).
As we did write more than than TPM_BUFSIZE bytes but tpm_write reports
that only TPM_BUFSIZE bytes have been written the vfs tries to write
the remaining bytes (in this case 10 bytes) to the tpm device driver via
tpm_write which then blocks at
/* cannot perform a write until the read has cleared
either via tpm_read or a user_read_timer timeout */
while (atomic_read(&chip->data_pending) != 0)
msleep(TPM_TIMEOUT);
for 60 seconds, since data_pending is -7 and nobody is able to
read it (since tpm_read luckily checks if data_pending is greater than
0) (#bug 2).
After that the remaining bytes are written to the TPM which are
interpreted by the tpm as a normal command. (bug #3)
So if the last bytes of the command stream happen to be a e.g.
tpm_force_clear this gets accidentally sent to the TPM.
This patch fixes all three bugs, by propagating the error code of
tpm_write and returning -E2BIG if the input buffer is too big,
since the response from the tpm for a truncated value is bogus anyway.
Moreover it returns -EBUSY to userspace if there is a response ready to be
read.
Signed-off-by: Peter Huewe <[email protected]>
Signed-off-by: Kent Yoder <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/tpm/tpm.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -1019,17 +1019,20 @@ ssize_t tpm_write(struct file *file, con
size_t size, loff_t *off)
{
struct tpm_chip *chip = file->private_data;
- size_t in_size = size, out_size;
+ size_t in_size = size;
+ ssize_t out_size;
/* cannot perform a write until the read has cleared
- either via tpm_read or a user_read_timer timeout */
- while (atomic_read(&chip->data_pending) != 0)
- msleep(TPM_TIMEOUT);
-
- mutex_lock(&chip->buffer_mutex);
+ either via tpm_read or a user_read_timer timeout.
+ This also prevents splitted buffered writes from blocking here.
+ */
+ if (atomic_read(&chip->data_pending) != 0)
+ return -EBUSY;
if (in_size > TPM_BUFSIZE)
- in_size = TPM_BUFSIZE;
+ return -E2BIG;
+
+ mutex_lock(&chip->buffer_mutex);
if (copy_from_user
(chip->data_buffer, (void __user *) buf, in_size)) {
@@ -1039,6 +1042,10 @@ ssize_t tpm_write(struct file *file, con
/* atomic tpm command send and result receive */
out_size = tpm_transmit(chip, chip->data_buffer, TPM_BUFSIZE);
+ if (out_size < 0) {
+ mutex_unlock(&chip->buffer_mutex);
+ return out_size;
+ }
atomic_set(&chip->data_pending, out_size);
mutex_unlock(&chip->buffer_mutex);
Patches currently in stable-queue which might be from [email protected]
are
queue-3.0/tpm-propagate-error-from-tpm_transmit-to-fix-a-timeout-hang.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
