linux-kernel - Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Feb 2021 11:52:58 +0100
From:   Lino Sanfilippo <l.sanfilippo@...bus.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>,
        Stefan Berger <stefanb@...ux.ibm.com>,
        Lino Sanfilippo <LinoSanfilippo@....de>, peterhuewe@....de,
        jarkko@...nel.org
Cc:     jgg@...pe.ca, stefanb@...ux.vnet.ibm.com, stable@...r.kernel.org,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] tpm: fix reference counting for struct tpm_chip

Hi,

On 05.02.21 03:01, James Bottomley wrote:
> On Thu, 2021-02-04 at 20:44 -0500, Stefan Berger wrote:
>> To clarify: When I tested this I had *both* patches applied. Without
>> the patches I got the null pointer exception in tpm2_del_space(). The
>> 2nd patch alone solves that issue when using the steps above.
> 
> 
> Yes, I can't confirm the bug either.  I only have lpc tis devices, so
> it could be something to do with spi, but when I do
>


> python3 in one shell
> 
>>>> fd = open("/dev/tpmrm0", "wb")
> 
> do rmmod tpm_tis in another shell
> 
>>>> buf = bytearray(20)
>>>> fd.write(buf)
> 20


The issue is in the TPM chip driver code, so AFAIU it should not matter whether its
SPI or something else. Maybe check again, that the file is still open when 
tpm_tis is removed and the write actually comes after the rmmod?
Also note that there are some sanity checks in tpm_common_write() that the written
data has to pass to get to the point where tpm_try_get_ops() is called, which 
is the call that eventually triggers the bug.

> 
> so I don't see the oops you see on write.  However
> 
>>>> fd.close()
> 
> And it oopses here in tpm2_del_space
> 
> James
> 
> 

Regards,
Lino