Re: Kernel 5.0 regression in /dev/tpm0 access

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Wed, Mar 13, 2019 at 03:59:26PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 12, 2019 at 03:42:00PM -0700, Tadeusz Struk wrote:
> > Hi Jarkko,
> > On 3/11/19 6:09 AM, Jarkko Sakkinen wrote:
> > > Tadeusz, why on earth the code does not lock buffer_mutex?? Just noticed
> > > when I checked the function in question. It is an awful bug alone.
> > 
> > Because the tpm_common_poll() just reads the flags and doesn't modify
> > them, so the logic was that if the response_length is not 0 or
> > response_read is flase then the first poll should return EPOLLIN
> > and if not, the application should call the poll again and only call read
> > if the EPOLLIN is set in the mask. It looks like the tpm_timeout_work()
> > kicks in and messes things out.
> 
> 1. You have *two* variables that you read, which can lead up reading
>    a partial state.
> 2. You are not using atomic_t even if there was one variable.
> 
> > Looking at it again I think the response_read flag is redundant
> > and only the response_length should be used.
> 
> Please provide a minimal fix to the issue. Only the fix for lock is
> needed and send a proper patch (did not read the code below).

Are you planning to submit a fix for this?

/Jarkko