linux-stable.git/drivers/char, branch v6.18.2

random: use offstack cpumask when necessary

2025-12-18T13:02:44+00:00

[ Upstream commit 5d49f1a5bd358d24e5f88b23b46da833de1dbec8 ]

The entropy generation function keeps a local cpu mask on the stack,
which can trigger warnings in configurations with a large number of
CPUs:

    drivers/char/random.c:1292:20: error: stack frame size (1288)
    exceeds limit (1280) in 'try_to_generate_entropy' [-Werror,-Wframe-larger-than]

Use the cpumask interface to dynamically allocate it in those
configurations.

Fixes: 1c21fe00eda7 ("random: spread out jitter callback to different CPUs")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Sasha Levin

tpm_crb: Add idle support for the Arm FF-A start method

2025-10-18T11:33:22+00:00

According to the CRB over FF-A specification [1], a TPM that implements
the ABI must comply with the TCG PTP specification. This requires support
for the Idle and Ready states.

This patch implements CRB control area requests for goIdle and
cmdReady on FF-A based TPMs.

The FF-A message used to notify the TPM of CRB updates includes a
locality parameter, which provides a hint to the TPM about which
locality modified the CRB.  This patch adds a locality parameter
to __crb_go_idle() and __crb_cmd_ready() to support this.

[1] https://developer.arm.com/documentation/den0138/latest/

Signed-off-by: Stuart Yoder 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

Merge tag 'for-linus-6.18-2' of https://github.com/cminyard/linux-ipmi

2025-10-14T16:15:45+00:00

Pull IPMI fixes from Corey Minyard:
 "A few bug fixes for patches that went in this release: a refcount
  error and some missing or incorrect error checks"

* tag 'for-linus-6.18-2' of https://github.com/cminyard/linux-ipmi:
  ipmi: Fix handling of messages with provided receive message pointer
  mfd: ls2kbmc: check for devm_mfd_add_devices() failure
  mfd: ls2kbmc: Fix an IS_ERR() vs NULL check in probe()

tpm: Prevent local DOS via tpm/tpm0/ppi/*operations

2025-10-10T05:21:45+00:00

Reads on tpm/tpm0/ppi/*operations can become very long on
misconfigured systems. Reading the TPM is a blocking operation,
thus a user could effectively trigger a DOS.

Resolve this by caching the results and avoiding the blocking
operations after the first read.

[ jarkko: fixed atomic sleep:
  sed -i 's/spin_/mutex_/g' drivers/char/tpm/tpm_ppi.c
  sed -i 's/DEFINE_SPINLOCK/DEFINE_MUTEX/g' drivers/char/tpm/tpm_ppi.c ]

Signed-off-by: Denis Aleksandrov 
Reported-by: Jan Stancek 
Closes: https://lore.kernel.org/linux-integrity/20250915210829.6661-1-daleksan@redhat.com/T/#u
Suggested-by: Jarkko Sakkinen 
Reviewed-by: Paul Menzel 
Signed-off-by: Jarkko Sakkinen

tpm: use a map for tpm2_calc_ordinal_duration()

2025-10-10T05:21:45+00:00

The current shenanigans for duration calculation introduce too much
complexity for a trivial problem, and further the code is hard to patch and
maintain.

Address these issues with a flat look-up table, which is easy to understand
and patch. If leaf driver specific patching is required in future, it is
easy enough to make a copy of this table during driver initialization and
add the chip parameter back.

'chip->duration' is retained for TPM 1.x.

As the first entry for this new behavior address TCG spec update mentioned
in this issue:

https://github.com/raspberrypi/linux/issues/7054

Therefore, for TPM_SelfTest the duration is set to 3000 ms.

This does not categorize a as bug, given that this is introduced to the
spec after the feature was originally made.

Reviewed-by: Serge Hallyn 
Signed-off-by: Jarkko Sakkinen

tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single

2025-10-10T05:21:45+00:00

The tpm_tis_write8() call specifies arguments in wrong order. Should be
(data, addr, value) not (data, value, addr). The initial correct order
was changed during the major refactoring when the code was split.

Fixes: 41a5e1cf1fe1 ("tpm/tpm_tis: Split tpm_tis driver into a core and TCG TIS compliant phy")
Signed-off-by: Gunnar Kudrjavets 
Reviewed-by: Justinien Bouron 
Reviewed-by: Jarkko Sakkinen 
Reviewed-by: Paul Menzel 
Signed-off-by: Jarkko Sakkinen

tpm: Use HMAC-SHA256 library instead of open-coded HMAC

2025-10-10T05:21:45+00:00

Now that there are easy-to-use HMAC-SHA256 library functions, use these
in tpm2-sessions.c instead of open-coding the HMAC algorithm.

Note that the new implementation correctly handles keys longer than 64
bytes (SHA256_BLOCK_SIZE), whereas the old implementation handled such
keys incorrectly.  But it doesn't appear that such keys were being used.

Signed-off-by: Eric Biggers 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen

tpm: Compare HMAC values in constant time

2025-10-10T05:21:45+00:00

In tpm_buf_check_hmac_response(), compare the HMAC values in constant
time using crypto_memneq() instead of in variable time using memcmp().

This is worthwhile to follow best practices and to be consistent with
MAC comparisons elsewhere in the kernel.  However, in this driver the
side channel seems to have been benign: the HMAC input data is
guaranteed to always be unique, which makes the usual MAC forgery via
timing side channel not possible.  Specifically, the HMAC input data in
tpm_buf_check_hmac_response() includes the "our_nonce" field, which was
generated by the kernel earlier, remains under the control of the
kernel, and is unique for each call to tpm_buf_check_hmac_response().

Signed-off-by: Eric Biggers 
Signed-off-by: Jarkko Sakkinen

tpm: Disable TPM2_TCG_HMAC by default

2025-10-10T05:21:45+00:00

After reading all the feedback, right now disabling the TPM2_TCG_HMAC
is the right call.

Other views discussed:

A. Having a kernel command-line parameter or refining the feature
   otherwise. This goes to the area of improvements.  E.g., one
   example is my own idea where the null key specific code would be
   replaced with a persistent handle parameter (which can be
   *unambigously* defined as part of attestation process when
   done correctly).

B. Removing the code. I don't buy this because that is same as saying
   that HMAC encryption cannot work at all (if really nitpicking) in
   any form. Also I disagree on the view that the feature could not
   be refined to something more reasoable.

Also, both A and B are worst options in terms of backporting.

Thuss, this is the best possible choice.

Cc: stable@vger.kernel.or # v6.10+
Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation")
Suggested-by: Chris Fenner 
Signed-off-by: Jarkko Sakkinen

ipmi: Fix handling of messages with provided receive message pointer

2025-10-07T11:50:08+00:00

Prior to commit b52da4054ee0 ("ipmi: Rework user message limit handling"),
i_ipmi_request() used to increase the user reference counter if the receive
message is provided by the caller of IPMI API functions. This is no longer
the case. However, ipmi_free_recv_msg() is still called and decreases the
reference counter. This results in the reference counter reaching zero,
the user data pointer is released, and all kinds of interesting crashes are
seen.

Fix the problem by increasing user reference counter if the receive message
has been provided by the caller.

Fixes: b52da4054ee0 ("ipmi: Rework user message limit handling")
Reported-by: Eric Dumazet 
Cc: Eric Dumazet 
Cc: Greg Thelen 
Signed-off-by: Guenter Roeck 
Message-ID: <20251006201857.3433837-1-linux@roeck-us.net>
Signed-off-by: Corey Minyard