All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] tpm: fix race condition in tpm_common_write()
@ 2018-05-22 21:37 Tadeusz Struk
  2018-05-23 13:50 ` Jarkko Sakkinen
  0 siblings, 1 reply; 7+ messages in thread
From: Tadeusz Struk @ 2018-05-22 21:37 UTC (permalink / raw)
  To: jarkko.sakkinen; +Cc: jgg, linux-integrity, 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 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.

v2: convert data_pending from atomic to a regular size_t type.

Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
---
 drivers/char/tpm/tpm-dev-common.c |   40 +++++++++++++++++--------------------
 drivers/char/tpm/tpm-dev.h        |    2 +-
 2 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/char/tpm/tpm-dev-common.c b/drivers/char/tpm/tpm-dev-common.c
index 230b99288024..e4a04b2d3c32 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -37,7 +37,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);
 }
@@ -46,7 +46,6 @@ void tpm_common_open(struct file *file, struct tpm_chip *chip,
 		     struct file_priv *priv)
 {
 	priv->chip = chip;
-	atomic_set(&priv->data_pending, 0);
 	mutex_init(&priv->buffer_mutex);
 	timer_setup(&priv->user_read_timer, user_reader_timeout, 0);
 	INIT_WORK(&priv->work, timeout_work);
@@ -58,29 +57,24 @@ ssize_t tpm_common_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 orig_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 */
-		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;
 }
 
@@ -91,17 +85,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 (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)) {
@@ -132,7 +128,7 @@ ssize_t tpm_common_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 */
@@ -149,5 +145,5 @@ void tpm_common_release(struct file *file, struct file_priv *priv)
 	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;
 }
diff --git a/drivers/char/tpm/tpm-dev.h b/drivers/char/tpm/tpm-dev.h
index ba3b6f9dacf7..b24cfb4d3ee1 100644
--- a/drivers/char/tpm/tpm-dev.h
+++ b/drivers/char/tpm/tpm-dev.h
@@ -8,7 +8,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 */

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] tpm: fix race condition in tpm_common_write()
  2018-05-22 21:37 [PATCH v2] tpm: fix race condition in tpm_common_write() Tadeusz Struk
@ 2018-05-23 13:50 ` Jarkko Sakkinen
  2018-05-30 17:13   ` Jarkko Sakkinen
  0 siblings, 1 reply; 7+ messages in thread
From: Jarkko Sakkinen @ 2018-05-23 13:50 UTC (permalink / raw)
  To: Tadeusz Struk; +Cc: jgg, linux-integrity

On Tue, May 22, 2018 at 02:37:18PM -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 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.
> 
> v2: convert data_pending from atomic to a regular size_t type.
> 
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> ---

The changel log should be here in diff stat (i.e. at this point) so that
the change log does not get pulled into the final commit message.

/Jarkko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] tpm: fix race condition in tpm_common_write()
  2018-05-23 13:50 ` Jarkko Sakkinen
@ 2018-05-30 17:13   ` Jarkko Sakkinen
  2018-05-30 17:24     ` Tadeusz Struk
  2018-05-30 20:54     ` Jarkko Sakkinen
  0 siblings, 2 replies; 7+ messages in thread
From: Jarkko Sakkinen @ 2018-05-30 17:13 UTC (permalink / raw)
  To: Tadeusz Struk; +Cc: jgg, linux-integrity

On Wed, May 23, 2018 at 04:50:03PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 22, 2018 at 02:37:18PM -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 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.
> > 
> > v2: convert data_pending from atomic to a regular size_t type.
> > 
> > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> > ---
> 
> The changel log should be here in diff stat (i.e. at this point) so that
> the change log does not get pulled into the final commit message.
> 
> /Jarkko

I pushed it now with appropriate tags, please check.

/Jarkko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] tpm: fix race condition in tpm_common_write()
  2018-05-30 17:13   ` Jarkko Sakkinen
@ 2018-05-30 17:24     ` Tadeusz Struk
  2018-05-30 20:54     ` Jarkko Sakkinen
  1 sibling, 0 replies; 7+ messages in thread
From: Tadeusz Struk @ 2018-05-30 17:24 UTC (permalink / raw)
  To: Jarkko Sakkinen; +Cc: jgg, linux-integrity

On 05/30/2018 10:13 AM, Jarkko Sakkinen wrote:
> I pushed it now with appropriate tags, please check.
Looks good. Thanks.
-- 
Tadeusz

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] tpm: fix race condition in tpm_common_write()
  2018-05-30 17:13   ` Jarkko Sakkinen
  2018-05-30 17:24     ` Tadeusz Struk
@ 2018-05-30 20:54     ` Jarkko Sakkinen
  2018-05-30 23:55       ` James Morris
  1 sibling, 1 reply; 7+ messages in thread
From: Jarkko Sakkinen @ 2018-05-30 20:54 UTC (permalink / raw)
  To: Tadeusz Struk, jmorris; +Cc: jgg, linux-integrity

James,

On Wed, May 30, 2018 at 08:13:15PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 23, 2018 at 04:50:03PM +0300, Jarkko Sakkinen wrote:
> > On Tue, May 22, 2018 at 02:37:18PM -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 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.
> > > 
> > > v2: convert data_pending from atomic to a regular size_t type.
> > > 
> > > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> > > ---
> > 
> > The changel log should be here in diff stat (i.e. at this point) so that
> > the change log does not get pulled into the final commit message.
> > 
> > /Jarkko
> 
> I pushed it now with appropriate tags, please check.
> 
> /Jarkko

Should I make a follow up PR for 4.18 with only this fix included?

/Jarkko

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] tpm: fix race condition in tpm_common_write()
  2018-05-30 20:54     ` Jarkko Sakkinen
@ 2018-05-30 23:55       ` James Morris
  2018-06-02 12:32         ` Jarkko Sakkinen
  0 siblings, 1 reply; 7+ messages in thread
From: James Morris @ 2018-05-30 23:55 UTC (permalink / raw)
  To: Jarkko Sakkinen; +Cc: Tadeusz Struk, jgg, linux-integrity

On Wed, 30 May 2018, Jarkko Sakkinen wrote:

> Should I make a follow up PR for 4.18 with only this fix included?

What about for current -rc?

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH v2] tpm: fix race condition in tpm_common_write()
  2018-05-30 23:55       ` James Morris
@ 2018-06-02 12:32         ` Jarkko Sakkinen
  0 siblings, 0 replies; 7+ messages in thread
From: Jarkko Sakkinen @ 2018-06-02 12:32 UTC (permalink / raw)
  To: James Morris; +Cc: Tadeusz Struk, jgg, linux-integrity

On Thu, May 31, 2018 at 09:55:00AM +1000, James Morris wrote:
> On Wed, 30 May 2018, Jarkko Sakkinen wrote:
> 
> > Should I make a follow up PR for 4.18 with only this fix included?
> 
> What about for current -rc?

I think so. I will do it.

/Jarkko

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-06-02 12:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-22 21:37 [PATCH v2] tpm: fix race condition in tpm_common_write() Tadeusz Struk
2018-05-23 13:50 ` Jarkko Sakkinen
2018-05-30 17:13   ` Jarkko Sakkinen
2018-05-30 17:24     ` Tadeusz Struk
2018-05-30 20:54     ` Jarkko Sakkinen
2018-05-30 23:55       ` James Morris
2018-06-02 12:32         ` Jarkko Sakkinen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.