[PATCH] tpm: fix race condition in tpm_common_write()

[PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

From: Tadeusz Struk <tadeusz.struk@intel.com>

commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream

There is a race condition in tpm_common_write function allowing
two threads on the same /dev/tpm<N>, or two different applications
on the same /dev/tpmrm<N> to overwrite each other commands/responses.
Fixed this by taking the priv->buffer_mutex early in the function.

Also converted the priv->data_pending from atomic to a regular size_t
type. There is no need for it to be atomic since it is only touched
under the protection of the priv->buffer_mutex.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
Manually backported for v4.4 and v4.9.
 drivers/char/tpm/tpm-dev.c | 43 ++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 23 deletions(-)

diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
index 65b824954bdc..1662e4688ee2 100644
--- a/drivers/char/tpm/tpm-dev.c
+++ b/drivers/char/tpm/tpm-dev.c
@@ -25,7 +25,7 @@ struct file_priv {
 	struct tpm_chip *chip;
 
 	/* Data passed to and from the tpm via the read/write calls */
-	atomic_t data_pending;
+	size_t data_pending;
 	struct mutex buffer_mutex;
 
 	struct timer_list user_read_timer;      /* user needs to claim result */
@@ -46,7 +46,7 @@ static void timeout_work(struct work_struct *work)
 	struct file_priv *priv = container_of(work, struct file_priv, work);
 
 	mutex_lock(&priv->buffer_mutex);
-	atomic_set(&priv->data_pending, 0);
+	priv->data_pending = 0;
 	memset(priv->data_buffer, 0, sizeof(priv->data_buffer));
 	mutex_unlock(&priv->buffer_mutex);
 }
@@ -72,7 +72,6 @@ static int tpm_open(struct inode *inode, struct file *file)
 	}
 
 	priv->chip = chip;
-	atomic_set(&priv->data_pending, 0);
 	mutex_init(&priv->buffer_mutex);
 	setup_timer(&priv->user_read_timer, user_reader_timeout,
 			(unsigned long)priv);
@@ -86,28 +85,24 @@ static ssize_t tpm_read(struct file *file, char __user *buf,
 			size_t size, loff_t *off)
 {
 	struct file_priv *priv = file->private_data;
-	ssize_t ret_size;
+	ssize_t ret_size = 0;
 	int rc;
 
 	del_singleshot_timer_sync(&priv->user_read_timer);
 	flush_work(&priv->work);
-	ret_size = atomic_read(&priv->data_pending);
-	if (ret_size > 0) {	/* relay data */
-		ssize_t orig_ret_size = ret_size;
-		if (size < ret_size)
-			ret_size = size;
+	mutex_lock(&priv->buffer_mutex);
 
-		mutex_lock(&priv->buffer_mutex);
+	if (priv->data_pending) {
+		ret_size = min_t(ssize_t, size, priv->data_pending);
 		rc = copy_to_user(buf, priv->data_buffer, ret_size);
-		memset(priv->data_buffer, 0, orig_ret_size);
+		memset(priv->data_buffer, 0, priv->data_pending);
 		if (rc)
 			ret_size = -EFAULT;
 
-		mutex_unlock(&priv->buffer_mutex);
+		priv->data_pending = 0;
 	}
 
-	atomic_set(&priv->data_pending, 0);
-
+	mutex_unlock(&priv->buffer_mutex);
 	return ret_size;
 }
 
@@ -118,18 +113,20 @@ static ssize_t tpm_write(struct file *file, const char __user *buf,
 	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.
-	   This also prevents splitted buffered writes from blocking here.
-	*/
-	if (atomic_read(&priv->data_pending) != 0)
-		return -EBUSY;
-
 	if (in_size > TPM_BUFSIZE)
 		return -E2BIG;
 
 	mutex_lock(&priv->buffer_mutex);
 
+	/* Cannot perform a write until the read has cleared either via
+	 * tpm_read or a user_read_timer timeout. This also prevents split
+	 * buffered writes from blocking here.
+	 */
+	if (priv->data_pending != 0) {
+		mutex_unlock(&priv->buffer_mutex);
+		return -EBUSY;
+	}
+
 	if (copy_from_user
 	    (priv->data_buffer, (void __user *) buf, in_size)) {
 		mutex_unlock(&priv->buffer_mutex);
@@ -159,7 +156,7 @@ static ssize_t tpm_write(struct file *file, const char __user *buf,
 		return out_size;
 	}
 
-	atomic_set(&priv->data_pending, out_size);
+	priv->data_pending = out_size;
 	mutex_unlock(&priv->buffer_mutex);
 
 	/* Set a timeout by which the reader must come claim the result */
@@ -178,7 +175,7 @@ static int tpm_release(struct inode *inode, struct file *file)
 	del_singleshot_timer_sync(&priv->user_read_timer);
 	flush_work(&priv->work);
 	file->private_data = NULL;
-	atomic_set(&priv->data_pending, 0);
+	priv->data_pending = 0;
 	clear_bit(0, &priv->chip->is_open);
 	kfree(priv);
 	return 0;
-- 
2.17.1

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Greg KH]

On Wed, Aug 08, 2018 at 03:35:50PM +0300, Jarkko Sakkinen wrote:
> From: Tadeusz Struk <tadeusz.struk@intel.com>
> 
> commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream
> 
> There is a race condition in tpm_common_write function allowing
> two threads on the same /dev/tpm<N>, or two different applications
> on the same /dev/tpmrm<N> to overwrite each other commands/responses.
> Fixed this by taking the priv->buffer_mutex early in the function.
> 
> Also converted the priv->data_pending from atomic to a regular size_t
> type. There is no need for it to be atomic since it is only touched
> under the protection of the priv->buffer_mutex.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> Manually backported for v4.4 and v4.9.

Now queued up, thanks.

greg k-h

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Fri, Aug 10, 2018 at 04:10:58PM +0200, Greg KH wrote:
> On Wed, Aug 08, 2018 at 03:35:50PM +0300, Jarkko Sakkinen wrote:
> > From: Tadeusz Struk <tadeusz.struk@intel.com>
> > 
> > commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream
> > 
> > There is a race condition in tpm_common_write function allowing
> > two threads on the same /dev/tpm<N>, or two different applications
> > on the same /dev/tpmrm<N> to overwrite each other commands/responses.
> > Fixed this by taking the priv->buffer_mutex early in the function.
> > 
> > Also converted the priv->data_pending from atomic to a regular size_t
> > type. There is no need for it to be atomic since it is only touched
> > under the protection of the priv->buffer_mutex.
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> > Manually backported for v4.4 and v4.9.
> 
> Now queued up, thanks.

Great, thank you.

> greg k-h

/Jarkko

[PATCH] tpm: fix race condition in tpm_common_write()

[Tadeusz Struk]

There is a race condition in tpm_common_write function allowing two
threads on the same /dev/tpm<N>, or two different applications on
the same /dev/tpmrm<N> to overwrite eachother requests/responses.

Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
---
 drivers/char/tpm/tpm-dev-common.c |   14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/char/tpm/tpm-dev-common.c b/drivers/char/tpm/tpm-dev-common.c
index 230b99288024..1ce6f989f40a 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -91,17 +91,19 @@ ssize_t tpm_common_write(struct file *file, const char __user *buf,
 	size_t in_size = size;
 	ssize_t out_size;
 
+	if (in_size > TPM_BUFSIZE)
+		return -E2BIG;
+
+	mutex_lock(&priv->buffer_mutex);
+
 	/* Cannot perform a write until the read has cleared either via
 	 * tpm_read or a user_read_timer timeout. This also prevents split
 	 * buffered writes from blocking here.
 	 */
-	if (atomic_read(&priv->data_pending) != 0)
+	if (atomic_read(&priv->data_pending) != 0) {
+		mutex_unlock(&priv->buffer_mutex);
 		return -EBUSY;
-
-	if (in_size > TPM_BUFSIZE)
-		return -E2BIG;
-
-	mutex_lock(&priv->buffer_mutex);
+	}
 
 	if (copy_from_user
 	    (priv->data_buffer, (void __user *) buf, in_size)) {

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Jason Gunthorpe]

On Tue, May 22, 2018 at 10:32:46AM -0700, Tadeusz Struk wrote:
> There is a race condition in tpm_common_write function allowing two
> threads on the same /dev/tpm<N>, or two different applications on
> the same /dev/tpmrm<N> to overwrite eachother requests/responses.
> 
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> ---
>  drivers/char/tpm/tpm-dev-common.c |   14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)

I didn't see any reasn for data_pending to be an atomic, ever use case
is near the buffer_mutex, can you respin this patch to just drop that
completely and only manipulate it within the lock?

Jason

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Tadeusz Struk]

On 05/22/2018 01:07 PM, Jason Gunthorpe wrote:
> I didn't see any reasn for data_pending to be an atomic, ever use case
> is near the buffer_mutex, can you respin this patch to just drop that
> completely and only manipulate it within the lock?

Yes, will do.
Thanks,
-- 
Tadeusz

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Tue, May 22, 2018 at 10:32:46AM -0700, Tadeusz Struk wrote:
> There is a race condition in tpm_common_write function allowing two
> threads on the same /dev/tpm<N>, or two different applications on
> the same /dev/tpmrm<N> to overwrite eachother requests/responses.
> 
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>

Ouch o_O Do you have a fixes tag for this one?

Thank you.

Reviewed-by: Jarkko Sakkien <jarkko.sakkinen@linux.intel.com>

/Jarkko

[PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Tue, May 22, 2018 at 10:32:46AM -0700, Tadeusz Struk wrote:
> There is a race condition in tpm_common_write function allowing two
> threads on the same /dev/tpm<N>, or two different applications on
> the same /dev/tpmrm<N> to overwrite eachother requests/responses.
> 
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>

Ouch o_O Do you have a fixes tag for this one?

Thank you.

Reviewed-by: Jarkko Sakkien <jarkko.sakkinen@linux.intel.com>

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Tadeusz Struk]

On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> Ouch o_O Do you have a fixes tag for this one?
> 

This one is quite tricky.
The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
and the code back then was in drivers/char/tpm/tpm-interface.c file

Then there were two other commits that moved the code around:
afdba32e2a9ea (tpm: Pull everything related to /dev/tpmX into tpm-dev.c)
which moved it from drivers/char/tpm/tpm-interface.c into drivers/char/tpm/tpm-dev.c

and last one, ecb38e2f521b0 (tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c)
which moved it from drivers/char/tpm/tpm-dev.c into tpm-common-dev.c

I have no idea how to tag it. Maybe we can use:
Fixes: ecb38e2f521b0 ("tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c")

And then it probably needs to be back ported manually all the way back to abce9ac292e13.

Thanks,
-- 
Tadeusz

[PATCH] tpm: fix race condition in tpm_common_write()

[Tadeusz Struk]

On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> Ouch o_O Do you have a fixes tag for this one?
> 

This one is quite tricky.
The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
and the code back then was in drivers/char/tpm/tpm-interface.c file

Then there were two other commits that moved the code around:
afdba32e2a9ea (tpm: Pull everything related to /dev/tpmX into tpm-dev.c)
which moved it from drivers/char/tpm/tpm-interface.c into drivers/char/tpm/tpm-dev.c

and last one, ecb38e2f521b0 (tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c)
which moved it from drivers/char/tpm/tpm-dev.c into tpm-common-dev.c

I have no idea how to tag it. Maybe we can use:
Fixes: ecb38e2f521b0 ("tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c")

And then it probably needs to be back ported manually all the way back to abce9ac292e13.

Thanks,
-- 
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Jason Gunthorpe]

On Wed, May 23, 2018 at 10:57:07AM -0700, Tadeusz Struk wrote:
> On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> > Ouch o_O Do you have a fixes tag for this one?
> > 
> 
> This one is quite tricky.
> The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
> and the code back then was in drivers/char/tpm/tpm-interface.c file

No, it has been wrong since before git history started, so just use

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

All the other commits you listed are just moving the bad code around
to new files.

Jason

[PATCH] tpm: fix race condition in tpm_common_write()

[Jason Gunthorpe]

On Wed, May 23, 2018 at 10:57:07AM -0700, Tadeusz Struk wrote:
> On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> > Ouch o_O Do you have a fixes tag for this one?
> > 
> 
> This one is quite tricky.
> The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
> and the code back then was in drivers/char/tpm/tpm-interface.c file

No, it has been wrong since before git history started, so just use

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

All the other commits you listed are just moving the bad code around
to new files.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Wed, May 23, 2018 at 01:41:15PM -0600, Jason Gunthorpe wrote:
> On Wed, May 23, 2018 at 10:57:07AM -0700, Tadeusz Struk wrote:
> > On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> > > Ouch o_O Do you have a fixes tag for this one?
> > > 
> > 
> > This one is quite tricky.
> > The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
> > and the code back then was in drivers/char/tpm/tpm-interface.c file
> 
> No, it has been wrong since before git history started, so just use
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> 
> All the other commits you listed are just moving the bad code around
> to new files.
> 
> Jason

OK, thank you Jason. I'll use that.

/Jarkko

[PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Wed, May 23, 2018 at 01:41:15PM -0600, Jason Gunthorpe wrote:
> On Wed, May 23, 2018 at 10:57:07AM -0700, Tadeusz Struk wrote:
> > On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> > > Ouch o_O Do you have a fixes tag for this one?
> > > 
> > 
> > This one is quite tricky.
> > The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
> > and the code back then was in drivers/char/tpm/tpm-interface.c file
> 
> No, it has been wrong since before git history started, so just use
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> 
> All the other commits you listed are just moving the bad code around
> to new files.
> 
> Jason

OK, thank you Jason. I'll use that.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Wed, May 23, 2018 at 10:57:07AM -0700, Tadeusz Struk wrote:
> On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> > Ouch o_O Do you have a fixes tag for this one?
> > 
> 
> This one is quite tricky.
> The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
> and the code back then was in drivers/char/tpm/tpm-interface.c file
> 
> Then there were two other commits that moved the code around:
> afdba32e2a9ea (tpm: Pull everything related to /dev/tpmX into tpm-dev.c)
> which moved it from drivers/char/tpm/tpm-interface.c into drivers/char/tpm/tpm-dev.c
> 
> and last one, ecb38e2f521b0 (tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c)
> which moved it from drivers/char/tpm/tpm-dev.c into tpm-common-dev.c
> 
> I have no idea how to tag it. Maybe we can use:
> Fixes: ecb38e2f521b0 ("tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c")
> 
> And then it probably needs to be back ported manually all the way back to abce9ac292e13.
> 
> Thanks,
> -- 
> Tadeusz

Thank you. I'll cc this to stable.

/Jarkko

[PATCH] tpm: fix race condition in tpm_common_write()

[Jarkko Sakkinen]

On Wed, May 23, 2018 at 10:57:07AM -0700, Tadeusz Struk wrote:
> On 05/23/2018 06:23 AM, Jarkko Sakkinen wrote:
> > Ouch o_O Do you have a fixes tag for this one?
> > 
> 
> This one is quite tricky.
> The original bug was introduced by abce9ac292e13 (tpm: Propagate error from tpm_transmit to fix a timeout hang)
> and the code back then was in drivers/char/tpm/tpm-interface.c file
> 
> Then there were two other commits that moved the code around:
> afdba32e2a9ea (tpm: Pull everything related to /dev/tpmX into tpm-dev.c)
> which moved it from drivers/char/tpm/tpm-interface.c into drivers/char/tpm/tpm-dev.c
> 
> and last one, ecb38e2f521b0 (tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c)
> which moved it from drivers/char/tpm/tpm-dev.c into tpm-common-dev.c
> 
> I have no idea how to tag it. Maybe we can use:
> Fixes: ecb38e2f521b0 ("tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c")
> 
> And then it probably needs to be back ported manually all the way back to abce9ac292e13.
> 
> Thanks,
> -- 
> Tadeusz

Thank you. I'll cc this to stable.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html