stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll
@ 2019-03-22 14:38 Tadeusz Struk
  2019-03-22 15:59 ` Jarkko Sakkinen
  0 siblings, 1 reply; 5+ messages in thread
From: Tadeusz Struk @ 2019-03-22 14:38 UTC (permalink / raw)
  To: jarkko.sakkinen
  Cc: grawity, James.Bottomley, linux-integrity, linux-kernel, stable,
	tadeusz.struk

The poll condition should only check response_length,
because reads should only be issued if there is data to read.
The response_read flag only prevents double writes.
The problem was that the write set the response_read to false,
enqued a tpm job, and returned. Then application called poll
which checked the response_read flag and returned EPOLLIN.
Then the application called read, but got nothing.
After all that the async_work kicked in.
Added also mutex_lock around the poll check to prevent
other possible race conditions.

Cc: stable@vger.kernel.org
Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads")
Reported-by: Mantas Mikulėnas <grawity@gmail.com>
Tested-by: Mantas Mikulėnas <grawity@gmail.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
---
 drivers/char/tpm/tpm-dev-common.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm-dev-common.c b/drivers/char/tpm/tpm-dev-common.c
index 5eecad233ea1..7312d3214381 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -203,12 +203,14 @@ __poll_t tpm_common_poll(struct file *file, poll_table *wait)
 	__poll_t mask = 0;
 
 	poll_wait(file, &priv->async_wait, wait);
+	mutex_lock(&priv->buffer_mutex);
 
-	if (!priv->response_read || priv->response_length)
+	if (priv->response_length)
 		mask = EPOLLIN | EPOLLRDNORM;
 	else
 		mask = EPOLLOUT | EPOLLWRNORM;
 
+	mutex_unlock(&priv->buffer_mutex);
 	return mask;
 }
 


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

* Re: [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll
  2019-03-22 14:38 [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll Tadeusz Struk
@ 2019-03-22 15:59 ` Jarkko Sakkinen
  2019-03-25 14:09   ` Jarkko Sakkinen
  0 siblings, 1 reply; 5+ messages in thread
From: Jarkko Sakkinen @ 2019-03-22 15:59 UTC (permalink / raw)
  To: Tadeusz Struk
  Cc: grawity, James.Bottomley, linux-integrity, linux-kernel, stable

On Fri, Mar 22, 2019 at 07:38:58AM -0700, Tadeusz Struk wrote:
> The poll condition should only check response_length,
> because reads should only be issued if there is data to read.
> The response_read flag only prevents double writes.
> The problem was that the write set the response_read to false,
> enqued a tpm job, and returned. Then application called poll
> which checked the response_read flag and returned EPOLLIN.
> Then the application called read, but got nothing.
> After all that the async_work kicked in.
> Added also mutex_lock around the poll check to prevent
> other possible race conditions.
> 
> Cc: stable@vger.kernel.org
> Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads")
> Reported-by: Mantas Mikulėnas <grawity@gmail.com>
> Tested-by: Mantas Mikulėnas <grawity@gmail.com>
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>

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

Thank you.

/Jarkko

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

* Re: [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll
  2019-03-22 15:59 ` Jarkko Sakkinen
@ 2019-03-25 14:09   ` Jarkko Sakkinen
  2019-03-26 15:58     ` Tadeusz Struk
  0 siblings, 1 reply; 5+ messages in thread
From: Jarkko Sakkinen @ 2019-03-25 14:09 UTC (permalink / raw)
  To: Tadeusz Struk
  Cc: grawity, James.Bottomley, linux-integrity, linux-kernel, stable

On Fri, Mar 22, 2019 at 05:59:17PM +0200, Jarkko Sakkinen wrote:
> On Fri, Mar 22, 2019 at 07:38:58AM -0700, Tadeusz Struk wrote:
> > The poll condition should only check response_length,
> > because reads should only be issued if there is data to read.
> > The response_read flag only prevents double writes.
> > The problem was that the write set the response_read to false,
> > enqued a tpm job, and returned. Then application called poll
> > which checked the response_read flag and returned EPOLLIN.
> > Then the application called read, but got nothing.
> > After all that the async_work kicked in.
> > Added also mutex_lock around the poll check to prevent
> > other possible race conditions.
> > 
> > Cc: stable@vger.kernel.org
> > Fixes: 9488585b21bef0df12 ("tpm: add support for partial reads")
> > Reported-by: Mantas Mikulėnas <grawity@gmail.com>
> > Tested-by: Mantas Mikulėnas <grawity@gmail.com>
> > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> 
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

It is still missing the comment I asked to add. Otherwise, it is good.

/Jarkko

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

* Re: [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll
  2019-03-25 14:09   ` Jarkko Sakkinen
@ 2019-03-26 15:58     ` Tadeusz Struk
  2019-03-27  4:28       ` Jarkko Sakkinen
  0 siblings, 1 reply; 5+ messages in thread
From: Tadeusz Struk @ 2019-03-26 15:58 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: grawity, James.Bottomley, linux-integrity, linux-kernel, stable

Hi Jarkko,
On 3/25/19 7:09 AM, Jarkko Sakkinen wrote:
> It is still missing the comment I asked to add. Otherwise, it is good.
> 

Sorry, I didn't see your email with the suggestion earlier.
To be honest I'm not sure if this comment adds much value, or if it is
even correct. The poll doesn't "succeed" or "fail". It just returns
a mask indicating if there is any data to read or if the user can write.

Isn't the commit message + 'git blame' enough to remember why it was
done this way?

Thanks,
-- 
Tadeusz

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

* Re: [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll
  2019-03-26 15:58     ` Tadeusz Struk
@ 2019-03-27  4:28       ` Jarkko Sakkinen
  0 siblings, 0 replies; 5+ messages in thread
From: Jarkko Sakkinen @ 2019-03-27  4:28 UTC (permalink / raw)
  To: Tadeusz Struk
  Cc: grawity, James.Bottomley, linux-integrity, linux-kernel, stable

On Tue, Mar 26, 2019 at 08:58:28AM -0700, Tadeusz Struk wrote:
> Hi Jarkko,
> On 3/25/19 7:09 AM, Jarkko Sakkinen wrote:
> > It is still missing the comment I asked to add. Otherwise, it is good.
> > 
> 
> Sorry, I didn't see your email with the suggestion earlier.
> To be honest I'm not sure if this comment adds much value, or if it is
> even correct. The poll doesn't "succeed" or "fail". It just returns
> a mask indicating if there is any data to read or if the user can write.
> 
> Isn't the commit message + 'git blame' enough to remember why it was
> done this way?

Comments in the code have also their time and place especially when
doing code reviews. Usually I like to have something in a site where
there has been a race even if it was for fairly trivial reason. If you
want to refine the comment to be more to the point, that is perfectly
fine.

/Jarkko

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

end of thread, other threads:[~2019-03-27  4:29 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-22 14:38 [PATCH RESEND v3] tpm: fix an invalid condition in tpm_common_poll Tadeusz Struk
2019-03-22 15:59 ` Jarkko Sakkinen
2019-03-25 14:09   ` Jarkko Sakkinen
2019-03-26 15:58     ` Tadeusz Struk
2019-03-27  4:28       ` Jarkko Sakkinen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).