laptop-kernel/drivers/char/tpm, branch master

tpm: Disable TPM on null key name mismatch

2026-09-29T19:15:21Z

The null key name check exists to protect against TPM reset attacks, so a mismatch should stop the device from serving further requests. Currently it does not disable the chip when it finds a mismatch. The mismatch is logged: tpm tpm0: null key integrity check failed but the chip keeps serving commands: / # tpm2_getcap -c properties-fixed TPM_PT_FAMILY_INDICATOR: as UINT32: 0x08322e3000 as string: "2.0" ... tpm2_load_null() where the null key name check is run sets the chip as disabled only if the rc is non zero. When the mismatch is seen, rc is zero at that point and it returns success. The other issue is that the caller expects the null key handle to be populated when the function returns 0 which it does here without writing the handle and proceeds assuming the null key handle is valid. During the test, I noticed that tpm2_start_auth_session() uses the uninitialized stack value as the key handle since tpm2_load_null() returns 0 despite the integrity failure and proceeds with TPM2_CC_START_AUTH_SESS with this value as salt key handle. Set rc to -ENODEV on the mismatch. The error path then disables the chip and returns the correct code to the caller. Tested in QEMU with swtpm and CONFIG_TCG_TPM2_HMAC=y by making TPM2_CC_CONTEXT_LOAD fail with TPM2_RC_INTEGRITY and changing the name of the re-created null key. The chip is now disabled on the mismatch. Fixes: cc7d8594342a ("tpm: Rollback tpm2_load_null()") Fixes: 423893fcbe7e ("tpm: Disable TPM on tpm2_create_primary() failure") Cc: stable@vger.kernel.org # v6.12+ Assisted-by: LLM Signed-off-by: Surendran Kanagaraj Link: https://lore.kernel.org/r/20260918000731.48657-1-surenkj@amazon.com Reviewed-by: Gunnar Kudrjavets Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm: fix off-by-four bounds check in tpm2_get_random()

2026-09-29T19:15:21Z

When the response carries the TPM2_ST_SESSIONS tag, tpm2_get_random() skips the 4-byte parameter size field before locating the random data, but the bounds check still validates the response length against TPM_HEADER_SIZE. A truncated response can pass the check and make memcpy() read up to 4 bytes past the response end, so stale buffer contents end up in the caller's random bytes. Fix this by checking the response length against 'offset', which already includes the skipped parameter size field. Cc: stable@vger.kernel.org # v6.12+ Fixes: 1b6d7f9eb150 ("tpm: add session encryption protection to tpm2_get_random()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260902074839.417419-1-yijiangshan%40kylinos.cn Signed-off-by: Jiangshan Yi Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/r/20260903035837.219284-1-yijiangshan@kylinos.cn Signed-off-by: Jarkko Sakkinen

tpm: Fix auth session leak in tpm2_get_random() error path

2026-09-29T19:15:21Z

When tpm_buf_fill_hmac_session() fails in tpm2_get_random(), the error path returns without calling tpm2_end_auth_session(), leaking the auth session. All other error paths in the function handle this correctly. Fixes: 3d9e043dab0a ("tpm-buf: Memory-safe allocations") Cc: stable@vger.kernel.orga # v6.12+ Signed-off-by: Jiangshan Yi Link: https://lore.kernel.org/r/20260902074839.417419-1-yijiangshan@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm: Fix heap buffer overflow in tpm_transmit_cmd()

2026-09-29T19:15:20Z

struct tpm_buf now uses an embedded flexible array for data, which is 6 bytes shorter than TPM_BUFSIZE due to the struct header. But tpm_transmit_cmd() still passes PAGE_SIZE to tpm_transmit(), and after clamping to TPM_BUFSIZE in tpm_try_transmit(), chip->ops->recv() can write past the end of data[] by 6 bytes. Pass buf->capacity to tpm_transmit() instead. Fixes: 3d9e043dab0a ("tpm-buf: Memory-safe allocations") Signed-off-by: Jiangshan Yi Link: https://lore.kernel.org/r/20260901062850.379870-1-yijiangshan@kylinos.cn Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm-buf: Add TPM buffer support header for standalone reuse

2026-08-25T15:13:37Z

Extract all the functions and definitions for TPM buffer handling and separate them into their own header. Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm-buf: Memory-safe allocations

2026-08-25T15:13:36Z

Decouple kzalloc from buffer creation, so that a managed allocation can be used: struct tpm_buf *buf __free(kfree) buf = kzalloc(TPM_BUFSIZE, GFP_KERNEL); if (!buf) return -ENOMEM; tpm_buf_init(buf, TPM_BUFSIZE); Alternatively, other allocations are also possible (static data, stack, etc) for example: u8 buf_data[512]; struct tpm_buf *buf = (struct tpm_buf *)buf_data; tpm_buf_init(buf, sizeof(buf_data)); This is achieved by embedding buffer's header inside the allocated blob, instead of having an outer wrapper. Reviewed-by: Stefan Berger Signed-off-by: Jarkko Sakkinen Tested-by: Srish Srinivasan Message-ID: <20260522013555.1063716-1-jarkko@kernel.org> Signed-off-by: Ross Philipson

tpm-buf: Remove chip parameter from tpm_buf_append_handle()

2026-08-25T15:13:36Z

Remove the TPM driver chip parameter from the function tpm_buf_append_handle(). The chip parameter is only for error logging which can be done with other facilities like WARN(). Message-ID: <20260125192526.782202-11-jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen Signed-off-by: Ross Philipson

tpm-buf: Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW

2026-08-25T15:13:36Z

Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW flags into the TPM_BUF_INVALID flag, as their behavior is identical (the only difference being the associated log messages). Message-ID: <20260125192526.782202-11-jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen Reviewed-by: Jonathan McDowell Signed-off-by: Ross Philipson

tpm: Move platform specific definitions to the new PTP header

2026-08-25T15:13:35Z

These are definitions for TPM 2.0 interface and interactions with the platform as defined in the TCG specification: These definitions are located here in a separate file to avoid conflicts with vendor specific TIS/FIFO definition (e.g. STMicroelectronics, Infineon Technologies, etc). This allows the TCG defined TIS/FIFO interface to be in a public header while the former chip specific implementations contain their own definitions. TPM 1.x family chips that adhere to the TCG specifications use the TIS/FIFO interface as defined here. TCG PC Client Platform TPM Profile (PTP) Specification - https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

tpm: Move TPM common base definitions to the command header

2026-08-25T15:13:35Z

These are top level definitions shared by both TPM 1 and 2 family chips. This includes core definitions like TPM localities, common crypto algorithm IDs, and the base TPM command header. Co-developed-by: Daniel P. Smith Signed-off-by: Daniel P. Smith Co-developed-by: Alec Brown Signed-off-by: Alec Brown Signed-off-by: Ross Philipson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen