linux-stable.git/drivers/char/tpm, branch linux-3.16.y

tpm: Fix off-by-one when reading binary_bios_measurements

2019-07-09T21:04:00+00:00

commit 64494d39ff630a63b5308042b20132b491e3706b upstream.

It is unable to read the entry when it is the only one in
binary_bios_measurements:

00000000  00 00 00 00 08 00 00 00  c4 2f ed ad 26 82 00 cb
00000010  1d 15 f9 78 41 c3 44 e7  9d ae 33 20 00 00 00 00
00000020

This is obviously a firmware problem on my linux machine:

	Manufacturer: Inspur
	Product Name: SA5212M4
	Version: 01

However, binary_bios_measurements should return it any way,
rather than nothing, after all its content is completely
valid.

Fixes: 55a82ab3181b ("tpm: add bios measurement log")
Signed-off-by: Jia Zhang 
Reviewd-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.16:
 - Fix an additional comparison in tpm1_bios_measurements_start()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete

2019-07-09T21:04:00+00:00

commit 442601e87a4769a8daba4976ec3afa5222ca211d upstream.

Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.

Fixes: a2871c62e186 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Stefan Berger 
Reviewed-by: Jerry Snitselaar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

tpm: fix race condition in tpm_common_write()

2018-11-20T18:05:05+00:00

commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream.

There is a race condition in tpm_common_write function allowing
two threads on the same /dev/tpm, or two different applications
on the same /dev/tpmrm 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.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Tadeusz Struk 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.16: adjust filenames, context]
Signed-off-by: Ben Hutchings

tpm: fix potential buffer overruns caused by bit glitches on the bus

2018-06-16T21:22:27+00:00

commit 3be23274755ee85771270a23af7691dc9b3a95db upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  If a bit does
flip it could cause an overrun if it's in one of the size parameters,
so sanity check that we're not overrunning the provided buffer when
doing a memcpy().

Signed-off-by: Jeremy Boone 
Signed-off-by: James Bottomley 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
[bwh: Backported to 3.16: Drop the TPM2 bits]
Signed-off-by: Ben Hutchings

tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus

2018-06-16T21:22:27+00:00

commit 9b8cb28d7c62568a5916bdd7ea1c9176d7f8f2ed upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone 
Signed-off-by: James Bottomley 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
Signed-off-by: Ben Hutchings

tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus

2018-06-16T21:22:27+00:00

commit f9d4d9b5a5ef2f017bc344fb65a58a902517173b upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone 
Signed-off-by: James Bottomley 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
Signed-off-by: Ben Hutchings

tpm_tis: fix potential buffer overruns caused by bit glitches on the bus

2018-06-16T21:22:27+00:00

commit 6bb320ca4a4a7b5b3db8c8d7250cc40002046878 upstream.

Discrete TPMs are often connected over slow serial buses which, on
some platforms, can have glitches causing bit flips.  In all the
driver _recv() functions, we need to use a u32 to unmarshal the
response size, otherwise a bit flip of the 31st bit would cause the
expected variable to go negative, which would then try to read a huge
amount of data.  Also sanity check that the expected amount of data is
large enough for the TPM header.

Signed-off-by: Jeremy Boone 
Signed-off-by: James Bottomley 
Tested-by: Jarkko Sakkinen 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

tpm-dev-common: Reject too short writes

2018-02-13T18:42:08+00:00

commit ee70bc1e7b63ac8023c9ff9475d8741e397316e7 upstream.

tpm_transmit() does not offer an explicit interface to indicate the number
of valid bytes in the communication buffer. Instead, it relies on the
commandSize field in the TPM header that is encoded within the buffer.
Therefore, ensure that a) enough data has been written to the buffer, so
that the commandSize field is present and b) the commandSize field does not
announce more data than has been written to the buffer.

This should have been fixed with CVE-2011-1161 long ago, but apparently
a correct version of that patch never made it into the kernel.

Signed-off-by: Alexander Steffen 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

tpm: fix a kernel memory leak in tpm-sysfs.c

2017-10-12T14:28:02+00:00

commit 13b47cfcfc60495cde216eef4c01040d76174cbe upstream.

While cleaning up sysfs callback that prints EK we discovered a kernel
memory leak. This commit fixes the issue by zeroing the buffer used for
TPM command/response.

The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or
xen-tpmfront.

Fixes: 0883743825e3 ("TPM: sysfs functions consolidation")
Reported-by: Jason Gunthorpe 
Tested-by: Stefan Berger 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: James Morris 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

tpm: read burstcount from TPM_STS in one 32-bit transaction

2016-11-20T01:16:54+00:00

commit 9754d45e997000ad4021bc4606cc266bb38d876f upstream.

Some chips incorrectly support partial reads from TPM_STS register
at non-zero offsets. Read the entire 32-bits register instead of
making two 8-bit reads to support such devices and reduce the number
of bus transactions when obtaining the burstcount from TPM_STS.

Fixes: 27084efee0c3 ("tpm: driver for next generation TPM chips")
Signed-off-by: Andrey Pronin 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
[bwh: Backported to 3.16:
 - Use raw ioread32() instead of tpm_tis_read32()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings