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]
Message-ID: <c6c3a432-0949-6755-8955-3d002f66184e@kunbus.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ