* [RFC PATCH 0/4] fix FF-A call failed with pKVM when ff-a driver is built-in
From: Yeoreum Yun @ 2026-04-17 17:57 UTC (permalink / raw)
To: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: paul, jmorris, serge, zohar, roberto.sassu, dmitry.kasatkin,
eric.snowberg, peterhuewe, jarkko, jgg, sudeep.holla, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will,
Yeoreum Yun
commit 0e0546eabcd6 ("firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall")
changed the initcall level of ffa_init() to rootfs_initcall to address
an issue where IMA could not properly recognize the TPM device
when FF-A driver is built as built-in.
However, this introduces another problem: pKVM fails to handle FF-A calls
because it cannot trap the FFA_VERSION call invoked by ffa_init().
To ensure the TPM device is recognized when present in the system,
it is preferable to invoke ima_init() at a later stage.
Deferred probing is resolved by deferred_probe_initcall(),
which runs at the late_initcall level.
Therefore, introduce an LSM initcall at late_initcall_sync and
move ima_init() to this level.
With this change, revert the initcall level of ffa_init() back to
device_initcall. Additionally, to handle the case where ffa_init() runs
before kvm_init(), check whether pKVM has been initialized during ffa_init().
If not, defer initialization to prevent failures of FF-A calls
due to the inability to trap FFA_VERSION and FFA_RXTX_MAP in pKVM.
This patch is based on v7.0
Yeoreum Yun (4):
security: ima: move ima_init into late_initcall_sync
tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa is built-in
firmware: arm_ffa: revert ffa_init() initcall level to device_initcall
firmware: arm_ffa: check pkvm initailised when initailise ffa driver
arch/arm64/kvm/arm.c | 1 +
drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
drivers/firmware/arm_ffa/driver.c | 14 +++++++++++++-
include/linux/lsm_hooks.h | 2 ++
security/integrity/ima/ima_main.c | 2 +-
security/lsm_init.c | 13 +++++++++++--
6 files changed, 31 insertions(+), 19 deletions(-)
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply
* Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
From: Petr Vorel @ 2026-04-17 17:11 UTC (permalink / raw)
To: Michał Grzelak
Cc: Oliver Sang, lkp, intel-gfx, Jani Nikula, oe-lkp, intel-xe, ltp,
linux-integrity, Mimi Zohar
In-Reply-To: <2df6f595-da57-0668-951c-657c5c876333@intel.com>
Hi Michał, all,
> Hi Petr & Oliver,
> > in our tests, it's quite persistent and clean on parent:
> I haven't reproduced it myself, but this issue seems somewhat related
> with issue observed earlier by CI [1]. I would expect it to not be a
> random glitch but a true bug related to the series.
> In previous versions of the series, during parsing there was a
> unfortunate snippet of:
> + const u32 *tables = block->tables;
> + size_t offset = 0;
> + size_t row_width;
> + const u32 *vals;
> +
> + row_width = block->num_columns * sizeof(*tables);
> +
> + for (int idx = 0; idx < block->num_tables; idx++) {
> + for (int row = 0; row < num_rows; row++) {
> + vals = &tables[offset];
> [...]
> + offset += row_width;
> + }
> + }
> Which caused hopping by 4 times more bytes than it should, because the
> sizeof() wasn't meant to be there. Since parsing takes place at module
> load, looks like it could be the issue. This seems especially convincing
> given that report is from parse_vswing_preemph_snps(). I have to also
> admit that it would be consistent with review comment from Sashiko [2].
> Lastly, sadly due to poorly split commits, 15th patch from v1 turned on
> whole VBT #57 searching. This probably caused bisect to point at 15th
> patch instead of pointing at patch adding parsing code, which would
> clearly show that patch/es introduce/s the bug.
> Anyways, now the bug should be fixed in v2 [3].
Michał, thanks a lot for pointing pointing this out.
Kind regards,
Petr
> [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164196v1/fi-hsw-4770/dmesg0.txt
> [2] https://sashiko.dev/#/patchset/20260331183332.1773886-1-michal.grzelak%40intel.com?part=5
> [3] https://lore.kernel.org/intel-gfx/20260415234639.3577774-21-michal.grzelak@intel.com/
> BR,
> Michał
^ permalink raw reply
* [PATCH] tpm: eventlog: remove unused structs tcg_algorithm_{size,info}
From: Thorsten Blum @ 2026-04-17 10:55 UTC (permalink / raw)
To: Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe
Cc: Thorsten Blum, linux-integrity, linux-kernel
Remove the unused structs tcg_algorithm_size and tcg_algorithm_info.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
include/linux/tpm_eventlog.h | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index aff8ea2fa98e..615bd0af5173 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -114,22 +114,6 @@ struct tcg_pcr_event2_head {
struct tpm_digest digests[];
} __packed;
-struct tcg_algorithm_size {
- u16 algorithm_id;
- u16 algorithm_size;
-};
-
-struct tcg_algorithm_info {
- u8 signature[16];
- u32 platform_class;
- u8 spec_version_minor;
- u8 spec_version_major;
- u8 spec_errata;
- u8 uintn_size;
- u32 number_of_algorithms;
- struct tcg_algorithm_size digest_sizes[];
-};
-
#ifndef TPM_MEMREMAP
static inline void *TPM_MEMREMAP(unsigned long start, size_t size)
{
^ permalink raw reply related
* Re: [PATCH v2] evm: terminate and bound the evm_xattrs read buffer
From: Roberto Sassu @ 2026-04-17 8:30 UTC (permalink / raw)
To: Pengpeng Hou, Mimi Zohar, Roberto Sassu
Cc: Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge Hallyn, linux-integrity, linux-security-module,
linux-kernel
In-Reply-To: <20260417223004.1-evm-xattrs-v2-pengpeng@iscas.ac.cn>
On 4/17/2026 2:44 PM, Pengpeng Hou wrote:
> evm_read_xattrs() allocates size + 1 bytes, fills them from the list of
> enabled xattrs, and then passes strlen(temp) to
> simple_read_from_buffer(). When no configured xattrs are enabled, the
> fill loop stores nothing and temp[0] remains uninitialized, so strlen()
> reads beyond initialized memory.
>
> Explicitly terminate the buffer after allocation, use snprintf() for
> each formatted line, and pass the accumulated length to
pass the accumulate length (without risk of truncation) to ...
> simple_read_from_buffer().
>
> Fixes: fa516b66a1bf ("EVM: Allow runtime modification of the set of verified xattrs")
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> Changes since v1:
> - add the Fixes tag
> - replace sprintf() with snprintf()
> - explicitly terminate the buffer instead of switching to kzalloc()
>
> security/integrity/evm/evm_secfs.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/security/integrity/evm/evm_secfs.c b/security/integrity/evm/evm_secfs.c
> index acd840461902..b7882a4ce9d0 100644
> --- a/security/integrity/evm/evm_secfs.c
> +++ b/security/integrity/evm/evm_secfs.c
> @@ -127,8 +127,8 @@ static ssize_t evm_read_xattrs(struct file *filp, char __user *buf,
> size_t count, loff_t *ppos)
> {
> char *temp;
> - int offset = 0;
> - ssize_t rc, size = 0;
> + size_t offset = 0, size = 0;
> + ssize_t rc;
> struct xattr_list *xattr;
>
> if (*ppos != 0)
> @@ -150,17 +150,18 @@ static ssize_t evm_read_xattrs(struct file *filp, char __user *buf,
> mutex_unlock(&xattr_list_mutex);
> return -ENOMEM;
> }
Please add a newline here.
> + temp[size] = '\0';
>
> list_for_each_entry(xattr, &evm_config_xattrnames, list) {
> if (!xattr->enabled)
> continue;
>
> - sprintf(temp + offset, "%s\n", xattr->name);
> - offset += strlen(xattr->name) + 1;
Also a comment like:
/*
* No truncation possible: size is computed over the same
* enabled xattrs under xattr_list_mutex, so offset never exceeds size.
*/
to motivate why it is fine to increment offset without checking.
Thanks
Roberto
> + offset += snprintf(temp + offset, size + 1 - offset, "%s\n",
> + xattr->name);
> }
>
> mutex_unlock(&xattr_list_mutex);
> - rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
> + rc = simple_read_from_buffer(buf, count, ppos, temp, offset);
>
> kfree(temp);
>
^ permalink raw reply
* Re: ima: audit log emitted from ima_collect_measurement when SIGKILL interrupts reads from slow-read filesystems
From: Roberto Sassu @ 2026-04-17 8:37 UTC (permalink / raw)
To: Danny Hu, linux-integrity
Cc: zohar, roberto.sassu, dmitry.kasatkin, Sahil Gupta,
Pierre De Abreu, Julien Gomes, Kunal Bharathi
In-Reply-To: <CAFn2k5C+AAp7MCCpsP+n8c_ghE-YkwQzy3d36jX9B1H3b+c9tg@mail.gmail.com>
On 4/10/2026 8:54 PM, Danny Hu wrote:
> When IMA appraisal/measurement is enabled for executables, an
> AUDIT_INTEGRITY_DATA (type=1800) audit message is emitted from
> ima_collect_measurement() if a process receives SIGKILL while reading
> a file from a slow-read filesystem.
>
> Configuration:
> - IMA policy configured: measure func=BPRM_CHECK mask=MAY_EXEC
> - stacked overlayfs with git binary on squashfs (compressed, read-only
> filesystem on flash storage)
> - Kernel version 6.12.68
>
> Steps to reproduce:
> $ echo 3 > /proc/sys/vm/drop_caches; timeout --signal=KILL 0.05s git
> Killed
> $ dmesg | tail -n 1
> audit: type=1800 audit(1775843687.948:10): pid=14049 uid=0
> auid=72198551 ses=2 op=collect_data cause=failed comm="timeout"
> name="git" dev="overlay" ino=11529215046068473654 res=0 errno=0
>
> The drop_caches evicts both the page cache (forcing squashfs to
> re-read and decompress from flash on the next access) and the inode
> cache (forcing IMA to re-hash). The timeout command execs git and
> sends SIGKILL after 50ms.
> During that window, IMA is reading the file page by page in
> integrity_kernel_read. Since the page cache is cold, the squashfs read
> path must decompress blocks from flash storage. This IO operation
> causes the kernel to check for signals and return -EINTR. This
> propagates up through integrity_kernel_rea to ima_calc_file_hash and
> finally ima_collect_measurement, which logs the collect_data failure.
>
> The log is more commonly observed during boot, when the page cache is
> cold and all binaries must be read from flash for the first time. Many
> services may start and stop concurrently, and any process that
> receives SIGKILL while IMA is reading the file from flash for the
> first time will produce this audit message.
>
> I believe this log is spurious because the process is being killed;
> therefore, an interrupted file read is the expected outcome. The audit
> message in this case does not indicate any integrity violations as the
> file has not been tampered with. Lastly, the log's presence can
> mislead administrators or monitoring tools into believing a security
> event occurred when it was only an expected process kill.
Hi Danny
it still shows an unexpected condition occurred in IMA. I think it is
worth keeping the audit message.
Thanks
Roberto
> Questions for the IMA maintainers:
> 1. Is this the intended behavior? Should ima_collect_measurement still
> emit the audit log when the failure is due to a fatal signal?
> 2. If not, could a potential fix be to skip the generation of the
> audit log in ima_collect_measurement (result == -EINTR &&
> fatal_signal_pending(current))?
>
> Thanks,
> Danny
^ permalink raw reply
* [PATCH v2] evm: terminate and bound the evm_xattrs read buffer
From: Pengpeng Hou @ 2026-04-17 12:44 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu
Cc: Dmitry Kasatkin, Eric Snowberg, Paul Moore, James Morris,
Serge Hallyn, linux-integrity, linux-security-module,
linux-kernel, pengpeng
In-Reply-To: <20260407153002.2-evm-xattrs-pengpeng@iscas.ac.cn>
evm_read_xattrs() allocates size + 1 bytes, fills them from the list of
enabled xattrs, and then passes strlen(temp) to
simple_read_from_buffer(). When no configured xattrs are enabled, the
fill loop stores nothing and temp[0] remains uninitialized, so strlen()
reads beyond initialized memory.
Explicitly terminate the buffer after allocation, use snprintf() for
each formatted line, and pass the accumulated length to
simple_read_from_buffer().
Fixes: fa516b66a1bf ("EVM: Allow runtime modification of the set of verified xattrs")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- add the Fixes tag
- replace sprintf() with snprintf()
- explicitly terminate the buffer instead of switching to kzalloc()
security/integrity/evm/evm_secfs.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/security/integrity/evm/evm_secfs.c b/security/integrity/evm/evm_secfs.c
index acd840461902..b7882a4ce9d0 100644
--- a/security/integrity/evm/evm_secfs.c
+++ b/security/integrity/evm/evm_secfs.c
@@ -127,8 +127,8 @@ static ssize_t evm_read_xattrs(struct file *filp, char __user *buf,
size_t count, loff_t *ppos)
{
char *temp;
- int offset = 0;
- ssize_t rc, size = 0;
+ size_t offset = 0, size = 0;
+ ssize_t rc;
struct xattr_list *xattr;
if (*ppos != 0)
@@ -150,17 +150,18 @@ static ssize_t evm_read_xattrs(struct file *filp, char __user *buf,
mutex_unlock(&xattr_list_mutex);
return -ENOMEM;
}
+ temp[size] = '\0';
list_for_each_entry(xattr, &evm_config_xattrnames, list) {
if (!xattr->enabled)
continue;
- sprintf(temp + offset, "%s\n", xattr->name);
- offset += strlen(xattr->name) + 1;
+ offset += snprintf(temp + offset, size + 1 - offset, "%s\n",
+ xattr->name);
}
mutex_unlock(&xattr_list_mutex);
- rc = simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
+ rc = simple_read_from_buffer(buf, count, ppos, temp, offset);
kfree(temp);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] evm: zero-initialize the evm_xattrs read buffer
From: Pengpeng Hou @ 2026-04-17 3:06 UTC (permalink / raw)
To: Roberto Sassu
Cc: Mimi Zohar, Dmitry Kasatkin, Eric Snowberg, Paul Moore,
James Morris, Serge Hallyn, linux-integrity,
linux-security-module, linux-kernel, pengpeng
In-Reply-To: <20260407153002.2-evm-xattrs-pengpeng@iscas.ac.cn>
Hi Roberto,
Thanks, I'll respin this.
I'll add the `Fixes:` tag, switch the formatting site to `snprintf()`,
and rework the empty-list handling so it does not depend on `kzalloc()`
for the terminator.
Thanks,
Pengpeng
^ permalink raw reply
* [PATCH v3 0/4] Add support for ML-DSA signature for EVM and IMA
From: Stefan Berger @ 2026-04-16 15:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module
Cc: linux-kernel, zohar, roberto.sassu, ebiggers, Stefan Berger
Based on IMA sigv3 type of signatures, add support for ML-DSA signature
for EVM and IMA. Use the existing ML-DSA hashless signing mode (pure mode).
Stefan
v3:
- new patches 1/4 and 2/4
- addressed Mimi's comments on v2
v2:
- Dropped 1/3
- Using "none" as hash_algo in 2/2
Stefan Berger (4):
integrity: Check for NULL returned by asymmetric_key_public_key
integrity: Check that algo parameter is within valid range
integrity: Refactor asymmetric_verify for reusability
integrity: Add support for sigv3 verification using ML-DSA keys
security/integrity/digsig_asymmetric.c | 152 +++++++++++++++++++++----
1 file changed, 131 insertions(+), 21 deletions(-)
base-commit: 82bbd447199ff1441031d2eaf9afe041550cf525
--
2.53.0
^ permalink raw reply
* [PATCH v3 3/4] integrity: Refactor asymmetric_verify for reusability
From: Stefan Berger @ 2026-04-16 15:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module
Cc: linux-kernel, zohar, roberto.sassu, ebiggers, Stefan Berger
In-Reply-To: <20260416154039.1648083-1-stefanb@linux.ibm.com>
Refactor asymmetric_verify for reusability. Have it call
asymmetric_verify_common with the signature verification key and the
public_key structure as parameters. sigv3 support for ML-DSA will need to
check the public key type first to decide how to do the signature
verification and therefore will have these parameters available for
calling asymmetric_verify_common.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
v3:
- added kernel-doc
- NULL pointer check on asymmetric_key_public_key return value
---
security/integrity/digsig_asymmetric.c | 62 ++++++++++++++++++--------
1 file changed, 43 insertions(+), 19 deletions(-)
diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
index ed171a627d18..a4eb73bba6d2 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -79,18 +79,25 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
return key;
}
-int asymmetric_verify(struct key *keyring, const char *sig,
- int siglen, const char *data, int datalen)
+/**
+ * asymmetric_verify_common -- sigv2 and sigv3 common verify function
+ * @key: The key to use for signature verification; caller must free it
+ * @pk: The associated public key; must not be NULL
+ * @sig: The xattr signature
+ * @siglen: The length of the xattr signature; must be at least
+ * sizeof(struct signature_v2_hdr)
+ * @data: The data to verify the signature on
+ * @datalen: Length of @data
+ */
+static int asymmetric_verify_common(const struct key *key,
+ const struct public_key *pk,
+ const char *sig, int siglen,
+ const char *data, int datalen)
{
- struct public_key_signature pks;
struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
- const struct public_key *pk;
- struct key *key;
+ struct public_key_signature pks;
int ret;
- if (siglen <= sizeof(*hdr))
- return -EBADMSG;
-
siglen -= sizeof(*hdr);
if (siglen != be16_to_cpu(hdr->sig_size))
@@ -99,19 +106,9 @@ int asymmetric_verify(struct key *keyring, const char *sig,
if (hdr->hash_algo >= HASH_ALGO__LAST)
return -ENOPKG;
- key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
- if (IS_ERR(key))
- return PTR_ERR(key);
-
memset(&pks, 0, sizeof(pks));
pks.hash_algo = hash_algo_name[hdr->hash_algo];
-
- pk = asymmetric_key_public_key(key);
- if (!pk) {
- ret = -ENOKEY;
- goto out;
- }
pks.pkey_algo = pk->pkey_algo;
if (!strcmp(pk->pkey_algo, "rsa")) {
pks.encoding = "pkcs1";
@@ -131,11 +128,38 @@ int asymmetric_verify(struct key *keyring, const char *sig,
pks.s_size = siglen;
ret = verify_signature(key, &pks);
out:
- key_put(key);
pr_debug("%s() = %d\n", __func__, ret);
return ret;
}
+int asymmetric_verify(struct key *keyring, const char *sig,
+ int siglen, const char *data, int datalen)
+{
+ struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
+ const struct public_key *pk;
+ struct key *key;
+ int ret;
+
+ if (siglen <= sizeof(*hdr))
+ return -EBADMSG;
+
+ key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
+ if (IS_ERR(key))
+ return PTR_ERR(key);
+ pk = asymmetric_key_public_key(key);
+ if (!pk) {
+ ret = -ENOKEY;
+ goto out;
+ }
+
+ ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
+
+out:
+ key_put(key);
+
+ return ret;
+}
+
/*
* calc_file_id_hash - calculate the hash of the ima_file_id struct data
* @type: xattr type [enum evm_ima_xattr_type]
--
2.53.0
^ permalink raw reply related
* [PATCH v3 4/4] integrity: Add support for sigv3 verification using ML-DSA keys
From: Stefan Berger @ 2026-04-16 15:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module
Cc: linux-kernel, zohar, roberto.sassu, ebiggers, Stefan Berger
In-Reply-To: <20260416154039.1648083-1-stefanb@linux.ibm.com>
Add support for sigv3 signature verification using ML-DSA in pure mode.
When a sigv3 signature is verified, first check whether the key to use
for verification is an ML-DSA key and therefore uses a hashless signature
verification scheme. The hashless signature verification method uses the
ima_file_id structure directly for signature verification rather than
its digest.
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
v3:
- Renamed err_exit label to 'out'
- Updated kernel-doc for new function
- Relying on algo verified by caller of asymmetric_verify_v3_hashless
- NULL pointer check on asymmetric_key_public_key return value
v2: Set hash_algo in public_key_signature to "none"
---
security/integrity/digsig_asymmetric.c | 89 ++++++++++++++++++++++++--
1 file changed, 84 insertions(+), 5 deletions(-)
diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
index a4eb73bba6d2..b4c23a0ed68f 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -204,20 +204,99 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
return rc;
}
+/**
+ * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
+ * @key: The key to use for signature verification; caller must free it
+ * @pk: The associated public key; must not be NULL
+ * @encoding: The encoding the key type uses
+ * @sig: The xattr signature
+ * @siglen: The length of the xattr signature; must be at least
+ * sizeof(struct signature_v2_hdr)
+ * @algo: hash algorithm [enum hash_algo]; caller must ensure valid value
+ * @digest: The file digest
+ *
+ * Create an ima_file_id structure and use it for signature verification
+ * directly. This can be used for ML-DSA in pure mode for example.
+ */
+static int asymmetric_verify_v3_hashless(struct key *key,
+ const struct public_key *pk,
+ const char *encoding,
+ const char *sig, int siglen,
+ u8 algo,
+ const u8 *digest)
+{
+ struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
+ struct ima_file_id file_id = {
+ .hash_type = hdr->type,
+ .hash_algorithm = algo,
+ };
+ size_t digest_size = hash_digest_size[algo];
+ struct public_key_signature pks = {
+ .m = (u8 *)&file_id,
+ .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
+ .s = hdr->sig,
+ .s_size = siglen - sizeof(*hdr),
+ .pkey_algo = pk->pkey_algo,
+ .hash_algo = "none",
+ .encoding = encoding,
+ };
+ int ret;
+
+ if (hdr->type != IMA_VERITY_DIGSIG &&
+ hdr->type != EVM_IMA_XATTR_DIGSIG &&
+ hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
+ return -EINVAL;
+
+ if (pks.s_size != be16_to_cpu(hdr->sig_size))
+ return -EBADMSG;
+
+ memcpy(file_id.hash, digest, digest_size);
+
+ ret = verify_signature(key, &pks);
+ pr_debug("%s() = %d\n", __func__, ret);
+ return ret;
+}
+
int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
const char *data, int datalen, u8 algo)
{
struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
struct ima_max_digest_data hash;
+ const struct public_key *pk;
+ struct key *key;
int rc;
if (algo >= HASH_ALGO__LAST)
return -ENOPKG;
- rc = calc_file_id_hash(hdr->type, algo, data, &hash);
- if (rc)
- return -EINVAL;
+ if (siglen <= sizeof(*hdr))
+ return -EBADMSG;
- return asymmetric_verify(keyring, sig, siglen, hash.digest,
- hash.hdr.length);
+ key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
+ if (IS_ERR(key))
+ return PTR_ERR(key);
+
+ pk = asymmetric_key_public_key(key);
+ if (!pk) {
+ rc = -ENOKEY;
+ goto out;
+ }
+ if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
+ rc = asymmetric_verify_v3_hashless(key, pk, "raw",
+ sig, siglen, algo, data);
+ } else {
+ rc = calc_file_id_hash(hdr->type, algo, data, &hash);
+ if (rc) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
+ hash.hdr.length);
+ }
+
+out:
+ key_put(key);
+
+ return rc;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/4] integrity: Check that algo parameter is within valid range
From: Stefan Berger @ 2026-04-16 15:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module
Cc: linux-kernel, zohar, roberto.sassu, ebiggers, Stefan Berger
In-Reply-To: <20260416154039.1648083-1-stefanb@linux.ibm.com>
Check that the algo parameter passed to calc_file_id_hash is within valid
range. Do this in asymmetric_verify_v3 since this value will also be passed
to a hashless signature verification function from here.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
security/integrity/digsig_asymmetric.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
index a791ad43b3fb..ed171a627d18 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -139,7 +139,7 @@ int asymmetric_verify(struct key *keyring, const char *sig,
/*
* calc_file_id_hash - calculate the hash of the ima_file_id struct data
* @type: xattr type [enum evm_ima_xattr_type]
- * @algo: hash algorithm [enum hash_algo]
+ * @algo: hash algorithm [enum hash_algo]; caller must ensure valid value
* @digest: pointer to the digest to be hashed
* @hash: (out) pointer to the hash
*
@@ -187,6 +187,9 @@ int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
struct ima_max_digest_data hash;
int rc;
+ if (algo >= HASH_ALGO__LAST)
+ return -ENOPKG;
+
rc = calc_file_id_hash(hdr->type, algo, data, &hash);
if (rc)
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/4] integrity: Check for NULL returned by asymmetric_key_public_key
From: Stefan Berger @ 2026-04-16 15:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module
Cc: linux-kernel, zohar, roberto.sassu, ebiggers, Stefan Berger
In-Reply-To: <20260416154039.1648083-1-stefanb@linux.ibm.com>
Check for a NULL pointer returned by asymmetric_key_public_key and return
-ENOKEY in this case.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
---
security/integrity/digsig_asymmetric.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
index 6e68ec3becbd..a791ad43b3fb 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -108,6 +108,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
pks.hash_algo = hash_algo_name[hdr->hash_algo];
pk = asymmetric_key_public_key(key);
+ if (!pk) {
+ ret = -ENOKEY;
+ goto out;
+ }
pks.pkey_algo = pk->pkey_algo;
if (!strcmp(pk->pkey_algo, "rsa")) {
pks.encoding = "pkcs1";
--
2.53.0
^ permalink raw reply related
* [GIT PULL] integrity: subsystem fixes for v7.1
From: Mimi Zohar @ 2026-04-16 13:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-integrity, linux-kernel, Roberto Sassu
Hi Linus,
There are 2 main changes, 1 feature removal, some code cleanup, and
a number of bug fixes.
Main changes:
- Detecting secure boot mode was limited to IMA. Make detecting secure boot
mode accessible to EVM and other LSMs.
- IMA sigv3 support was limited to fsverity. Add IMA sigv3 support for IMA
regular file hashes and EVM portable signatures.
Remove:
- Remove IMA support for asychronous hash calculation originally added for
hardware acceleration.
Cleanup:
- Remove unnecessary Kconfig CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG tests.
- Add descriptions of the IMA atomic flags.
Bug fixes:
- Like IMA, properly limit EVM "fix" mode.
- Define and call evm_fix_hmac() to update security.evm.
- Fallback to using i_version to detect file change for filesystems that do not
support STATX_CHANGE_COOKIE.
- Address missing kernel support for configured (new) TPM hash algorithms.
- Add missing crypto_shash_final() return value.
Thanks,
Mimi
The following changes since commit 11439c4635edd669ae435eec308f4ab8a0804808:
Linux 7.0-rc2 (2026-03-01 15:39:31 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/ tags/integrity-v7.1
for you to fetch changes up to 82bbd447199ff1441031d2eaf9afe041550cf525:
evm: Enforce signatures version 3 with new EVM policy 'bit 3' (2026-04-01 10:16:53 -0400)
----------------------------------------------------------------
integrity-v7.1
----------------------------------------------------------------
Coiby Xu (5):
integrity: Make arch_ima_get_secureboot integrity-wide
evm: Don't enable fix mode when secure boot is enabled
s390: Drop unnecessary CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT
evm: fix security.evm for a file with IMA signature
ima: Add code comments to explain IMA iint cache atomic_flags
Daniel Hodges (1):
ima: check return value of crypto_shash_final() in boot aggregate
Dmitry Safonov (1):
ima_fs: Correctly create securityfs files for unsupported hash algos
Eric Biggers (1):
ima: remove buggy support for asynchronous hashes
Mimi Zohar (4):
ima: fallback to using i_version to detect file change
ima: Define asymmetric_verify_v3() to verify IMA sigv3 signatures
ima: add regular file data hash signature version 3 support
ima: add support to require IMA sigv3 signatures
Nathan Chancellor (1):
integrity: Eliminate weak definition of arch_get_secureboot()
Roberto Sassu (1):
ima: Define and use a digest_size field in the ima_algo_desc structure
Stefan Berger (2):
integrity: Allow sigv3 verification on EVM_XATTR_PORTABLE_DIGSIG
evm: Enforce signatures version 3 with new EVM policy 'bit 3'
Thomas Weißschuh (2):
ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG
powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG
Documentation/ABI/testing/evm | 1 +
Documentation/ABI/testing/ima_policy | 10 +-
Documentation/admin-guide/kernel-parameters.txt | 17 --
MAINTAINERS | 1 +
arch/Kconfig | 3 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/ima_arch.c | 8 +-
arch/powerpc/kernel/secure_boot.c | 6 +
arch/s390/Kconfig | 2 +-
arch/s390/kernel/Makefile | 1 -
arch/s390/kernel/ima_arch.c | 14 -
arch/s390/kernel/ipl.c | 6 +
arch/x86/include/asm/efi.h | 4 +-
arch/x86/platform/efi/efi.c | 2 +-
include/linux/evm.h | 8 +
include/linux/ima.h | 7 +-
include/linux/secure_boot.h | 23 ++
security/integrity/Makefile | 1 +
security/integrity/digsig.c | 8 +-
security/integrity/digsig_asymmetric.c | 59 ++++
security/integrity/efi_secureboot.c | 56 ++++
security/integrity/evm/evm.h | 3 +-
security/integrity/evm/evm_main.c | 69 ++++-
security/integrity/ima/ima.h | 29 +-
security/integrity/ima/ima_api.c | 13 +-
security/integrity/ima/ima_appraise.c | 79 ++---
security/integrity/ima/ima_crypto.c | 390 +-----------------------
security/integrity/ima/ima_efi.c | 53 +---
security/integrity/ima/ima_fs.c | 34 ++-
security/integrity/ima/ima_main.c | 37 ++-
security/integrity/ima/ima_policy.c | 22 +-
security/integrity/integrity.h | 15 +-
security/integrity/platform_certs/load_uefi.c | 2 +-
33 files changed, 398 insertions(+), 586 deletions(-)
delete mode 100644 arch/s390/kernel/ima_arch.c
create mode 100644 include/linux/secure_boot.h
create mode 100644 security/integrity/efi_secureboot.c
^ permalink raw reply
* Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
From: Michał Grzelak @ 2026-04-16 9:17 UTC (permalink / raw)
To: Oliver Sang
Cc: Petr Vorel, Michał Grzelak, lkp, intel-gfx, Jani Nikula,
oe-lkp, intel-xe, ltp, linux-integrity, Mimi Zohar
In-Reply-To: <aeCShTeoW+lmHjHF@xsang-OptiPlex-9020>
[-- Attachment #1: Type: text/plain, Size: 18161 bytes --]
Hi Petr & Oliver,
On Thu, 16 Apr 2026, Oliver Sang wrote:
> hi, Petr,
>
> On Thu, Apr 16, 2026 at 08:40:51AM +0200, Petr Vorel wrote:
>> Hi all,
>>
>> [ Cc Mimi and linux-integrity ]
>>> Hello,
>>
>>> kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_parse_vswing_preemph_snps" on:
>>
>>> commit: 07d1ee54da4966c1457602dc088a8a43b29254cb ("[PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default")
>>> url: https://github.com/intel-lab-lkp/linux/commits/Micha-Grzelak/drm-i915-lt-align-xe3plpd-with-VS-PE-Override-layout/20260401-092928
>>> base: https://gitlab.freedesktop.org/drm/i915/kernel.git for-linux-next
>>> patch link: https://lore.kernel.org/all/20260331183332.1773886-16-michal.grzelak@intel.com/
>>> patch subject: [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
>>
>>> in testcase: ltp
>>> version:
>>> with following parameters:
>>
>>> test: ima
>>
>>
>>
>>> config: x86_64-rhel-9.4-ltp
>>> compiler: gcc-14
>>> test machine: 22 threads 1 sockets Intel(R) Core(TM) Ultra 9 185H @ 4.5GHz (Meteor Lake) with 32G memory
>>
>>> (please refer to attached dmesg/kmsg for entire log/backtrace)
>>
>>
>>
>>> If you fix the issue in a separate patch/commit (i.e. not just a new version of
>>> the same patch/commit), kindly add following tags
>>> | Reported-by: kernel test robot <oliver.sang@intel.com>
>>> | Closes: https://lore.kernel.org/oe-lkp/202604150702.d409a2b6-lkp@intel.com
>>
>>
>>> The kernel config and materials to reproduce are available at:
>>> https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com
>>
>>
>>> kern :err : [ 27.966990] [ T399] ==================================================================
>>> kern :err : [ 27.968126] [ T399] BUG: KASAN: slab-out-of-bounds in parse_vswing_preemph_snps+0x2dd/0x430 [i915]
>>> kern :err : [ 27.969712] [ T399] Read of size 4 at addr ffff8881eba2c49d by task (udev-worker)/399
>>
>>> kern :err : [ 27.971135] [ T399] CPU: 4 UID: 0 PID: 399 Comm: (udev-worker) Tainted: G S 7.0.0-rc4-01496-g07d1ee54da49 #1 PREEMPT(lazy)
>>> kern :err : [ 27.971139] [ T399] Tainted: [S]=CPU_OUT_OF_SPEC
>>> kern :err : [ 27.971140] [ T399] Hardware name: ASUSTeK COMPUTER INC. NUC14RVS-B/NUC14RVSU9, BIOS RVMTL357.0047.2025.0108.1408 01/08/2025
>>> kern :err : [ 27.971142] [ T399] Call Trace:
>>> kern :err : [ 27.971144] [ T399] <TASK>
>>> kern :err : [ 27.971145] [ T399] dump_stack_lvl+0x47/0x70
>>> kern :err : [ 27.971152] [ T399] print_address_description+0x88/0x320
>>> kern :err : [ 27.971156] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
>>> kern :err : [ 27.971355] [ T399] print_report+0x106/0x1f4
>>> kern :err : [ 27.971357] [ T399] ? __virt_addr_valid+0xc4/0x230
>>> kern :err : [ 27.971360] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
>>> kern :err : [ 27.971533] [ T399] kasan_report+0xb5/0xf0
>>> kern :err : [ 27.971537] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
>>> kern :err : [ 27.971704] [ T399] parse_vswing_preemph_snps+0x2dd/0x430 [i915]
>>> kern :err : [ 27.971868] [ T399] intel_bios_init+0xcc1/0x14b0 [i915]
>>> kern :err : [ 27.972042] [ T399] ? drm_vblank_init+0x147/0x330 [drm]
>>> kern :err : [ 27.972105] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
>>> kern :err : [ 27.972295] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
>>> kern :err : [ 27.972445] [ T399] ? __pfx_mutex_lock+0x10/0x10
>>> kern :err : [ 27.972450] [ T399] ? mutex_lock+0x91/0xf0
>>> kern :err : [ 27.972451] [ T399] ? __pfx_i915_driver_probe+0x10/0x10 [i915]
>>> kern :err : [ 27.972597] [ T399] ? drm_privacy_screen_get+0x2bf/0x370 [drm]
>>> kern :err : [ 27.972628] [ T399] ? intel_display_driver_probe_defer+0x41/0x70 [i915]
>>> kern :err : [ 27.972814] [ T399] ? i915_pci_probe+0x2ab/0x3b0 [i915]
>>> kern :err : [ 27.972963] [ T399] ? __pfx_i915_pci_probe+0x10/0x10 [i915]
>>> kern :err : [ 27.973110] [ T399] local_pci_probe+0xdb/0x1b0
>>> kern :err : [ 27.973114] [ T399] pci_call_probe+0x153/0x4f0
>>> kern :err : [ 27.973116] [ T399] ? __pfx_pci_call_probe+0x10/0x10
>>> kern :err : [ 27.973117] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
>>> kern :err : [ 27.973119] [ T399] ? pci_assign_irq+0x80/0x2f0
>>> kern :err : [ 27.973121] [ T399] ? pci_match_device+0x38d/0x6b0
>>> kern :err : [ 27.973123] [ T399] ? kernfs_create_link+0x164/0x230
>>> kern :err : [ 27.973127] [ T399] pci_device_probe+0x173/0x2f0
>>> kern :err : [ 27.973128] [ T399] call_driver_probe+0x62/0x1f0
>>> kern :err : [ 27.973132] [ T399] really_probe+0x197/0x770
>>> kern :err : [ 27.973134] [ T399] __driver_probe_device+0x18c/0x3b0
>>> kern :err : [ 27.973137] [ T399] driver_probe_device+0x4a/0x130
>>> kern :err : [ 27.973139] [ T399] __driver_attach+0x18c/0x4f0
>>> kern :err : [ 27.973141] [ T399] ? __pfx___driver_attach+0x10/0x10
>>> kern :err : [ 27.973143] [ T399] bus_for_each_dev+0xef/0x170
>>> kern :err : [ 27.973145] [ T399] ? kasan_unpoison+0x40/0x70
>>> kern :err : [ 27.973147] [ T399] ? __pfx_bus_for_each_dev+0x10/0x10
>>> kern :err : [ 27.973149] [ T399] ? __kasan_slab_alloc+0x2f/0x70
>>> kern :err : [ 27.973152] [ T399] ? klist_add_tail+0x132/0x270
>>> kern :err : [ 27.973154] [ T399] bus_add_driver+0x2a7/0x4f0
>>> kern :err : [ 27.973156] [ T399] driver_register+0x1a1/0x370
>>> kern :err : [ 27.973158] [ T399] i915_init+0x57/0x160 [i915]
>>> kern :err : [ 27.973307] [ T399] ? __pfx_i915_init+0x10/0x10 [i915]
>>> kern :err : [ 27.973453] [ T399] do_one_initcall+0x8d/0x3f0
>>> kern :err : [ 27.973455] [ T399] ? __pfx_do_one_initcall+0x10/0x10
>>> kern :err : [ 27.973457] [ T399] ? kasan_unpoison+0x3b/0x70
>>> kern :err : [ 27.973458] [ T399] ? kasan_unpoison+0x40/0x70
>>> kern :err : [ 27.973460] [ T399] do_init_module+0x281/0x830
>>> kern :err : [ 27.973463] [ T399] ? __pfx_do_init_module+0x10/0x10
>>> kern :err : [ 27.973464] [ T399] ? kfree+0x195/0x430
>>> kern :err : [ 27.973467] [ T399] load_module+0x173d/0x2070
>>> kern :err : [ 27.973469] [ T399] ? ima_post_read_file+0x18f/0x230
>>
>> I'm surprised, but indeed it's could be triggered by IMA.
>>
>> Looking at full dmesg [1] I'm surprised that this is triggered before tests are
>> actually run and there is no IMA specific kernel command line parameter. That
>> means that error is not related to any LTP test.
>>
>> Is it always reproducible or just a random glitch?
>
> in our tests, it's quite persistent and clean on parent:
I haven't reproduced it myself, but this issue seems somewhat related
with issue observed earlier by CI [1]. I would expect it to not be a
random glitch but a true bug related to the series.
In previous versions of the series, during parsing there was a
unfortunate snippet of:
+ const u32 *tables = block->tables;
+ size_t offset = 0;
+ size_t row_width;
+ const u32 *vals;
+
+ row_width = block->num_columns * sizeof(*tables);
+
+ for (int idx = 0; idx < block->num_tables; idx++) {
+ for (int row = 0; row < num_rows; row++) {
+ vals = &tables[offset];
[...]
+ offset += row_width;
+ }
+ }
Which caused hopping by 4 times more bytes than it should, because the
sizeof() wasn't meant to be there. Since parsing takes place at module
load, looks like it could be the issue. This seems especially convincing
given that report is from parse_vswing_preemph_snps(). I have to also
admit that it would be consistent with review comment from Sashiko [2].
Lastly, sadly due to poorly split commits, 15th patch from v1 turned on
whole VBT #57 searching. This probably caused bisect to point at 15th
patch instead of pointing at patch adding parsing code, which would
clearly show that patch/es introduce/s the bug.
Anyways, now the bug should be fixed in v2 [3].
[1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164196v1/fi-hsw-4770/dmesg0.txt
[2] https://sashiko.dev/#/patchset/20260331183332.1773886-1-michal.grzelak%40intel.com?part=5
[3] https://lore.kernel.org/intel-gfx/20260415234639.3577774-21-michal.grzelak@intel.com/
BR,
Michał
> =========================================================================================
> tbox_group/testcase/rootfs/kconfig/compiler/test:
> igk-mtl-nuc02/ltp/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/ima
>
> e3d53a63657f3213 07d1ee54da4966c1457602dc088
> ---------------- ---------------------------
> fail:runs %reproduction fail:runs
> | | |
> :6 100% 6:6 dmesg.BUG:KASAN:slab-out-of-bounds_in_parse_vswing_preemph_snps
>
>
>>
>> ima_post_read_file() is a part of IMA core therefore issue might be not related
>> to any config, but just FYI kernel config [2].
>>
>> Kind regards,
>> Petr
>>
>> [1] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/kmsg.xz
>> [2] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/config-7.0.0-rc4-01496-g07d1ee54da49
>>
>>> kern :err : [ 27.973474] [ T399] ? __pfx_load_module+0x10/0x10
>>> kern :err : [ 27.973476] [ T399] ? security_kernel_post_read_file+0x35/0xf0
>>> kern :err : [ 27.973479] [ T399] ? __pfx_kernel_read_file+0x10/0x10
>>> kern :err : [ 27.973483] [ T399] ? __pfx_current_time+0x10/0x10
>>> kern :err : [ 27.973486] [ T399] ? init_module_from_file+0x157/0x1b0
>>> kern :err : [ 27.973487] [ T399] init_module_from_file+0x157/0x1b0
>>> kern :err : [ 27.973489] [ T399] ? __pfx_init_module_from_file+0x10/0x10
>>> kern :err : [ 27.973491] [ T399] ? touch_atime+0x1bc/0x4f0
>>> kern :err : [ 27.973493] [ T399] ? _raw_spin_lock+0x80/0xf0
>>> kern :err : [ 27.973494] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
>>> kern :err : [ 27.973496] [ T399] ? __pfx_filemap_read+0x10/0x10
>>> kern :err : [ 27.973498] [ T399] ? do_sys_openat2+0xeb/0x170
>>> kern :err : [ 27.973501] [ T399] idempotent_init_module+0x21c/0x770
>>> kern :err : [ 27.973503] [ T399] ? __pfx_idempotent_init_module+0x10/0x10
>>> kern :err : [ 27.973505] [ T399] ? fdget+0x54/0x3b0
>>> kern :err : [ 27.973506] [ T399] ? security_capable+0x35/0xf0
>>> kern :err : [ 27.973509] [ T399] __x64_sys_finit_module+0xca/0x170
>>> kern :err : [ 27.973511] [ T399] do_syscall_64+0x108/0x5b0
>>> kern :err : [ 27.973513] [ T399] ? vfs_read+0x3be/0x9b0
>>> kern :err : [ 27.973514] [ T399] ? vfs_read+0x3be/0x9b0
>>> kern :err : [ 27.973516] [ T399] ? __pfx_vfs_read+0x10/0x10
>>> kern :err : [ 27.973517] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
>>> kern :err : [ 27.973519] [ T399] ? fdget+0x54/0x3b0
>>> kern :err : [ 27.973520] [ T399] ? __pfx___seccomp_filter+0x10/0x10
>>> kern :err : [ 27.973523] [ T399] ? __x64_sys_pread64+0x18d/0x1f0
>>> kern :err : [ 27.973525] [ T399] ? __pfx___x64_sys_pread64+0x10/0x10
>>> kern :err : [ 27.973526] [ T399] ? fdget+0x54/0x3b0
>>> kern :err : [ 27.973528] [ T399] ? security_capable+0x35/0xf0
>>> kern :err : [ 27.973530] [ T399] ? do_syscall_64+0x140/0x5b0
>>> kern :err : [ 27.973531] [ T399] ? arch_exit_to_user_mode_prepare+0x9e/0xf0
>>> kern :err : [ 27.973533] [ T399] ? do_syscall_64+0x140/0x5b0
>>> kern :err : [ 27.973534] [ T399] ? __x64_sys_openat+0x104/0x1f0
>>> kern :err : [ 27.973536] [ T399] ? __pfx___x64_sys_openat+0x10/0x10
>>> kern :err : [ 27.973538] [ T399] ? do_syscall_64+0x140/0x5b0
>>> kern :err : [ 27.973540] [ T399] ? do_syscall_64+0x140/0x5b0
>>> kern :err : [ 27.973541] [ T399] ? irqentry_exit+0x76/0x4f0
>>> kern :err : [ 27.973544] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>> kern :err : [ 27.973546] [ T399] RIP: 0033:0x7f3689aa8779
>>> kern :err : [ 27.973549] [ T399] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 67 76 0d 00 f7 d8 64 89 01 48
>>> kern :err : [ 27.973551] [ T399] RSP: 002b:00007ffca3326338 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
>>> kern :err : [ 27.973555] [ T399] RAX: ffffffffffffffda RBX: 000055c94afdd3e0 RCX: 00007f3689aa8779
>>> kern :err : [ 27.973556] [ T399] RDX: 0000000000000000 RSI: 00007f36882ae44d RDI: 0000000000000053
>>> kern :err : [ 27.973557] [ T399] RBP: 0000000000000000 R08: 0000000000000000 R09: 000055c94af65b30
>>> kern :err : [ 27.973558] [ T399] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f36882ae44d
>>> kern :err : [ 27.973559] [ T399] R13: 0000000000020000 R14: 000055c94afb65f0 R15: 0000000000000000
>>> kern :err : [ 27.973561] [ T399] </TASK>
>>
>>> kern :err : [ 28.051757] [ T399] Allocated by task 399:
>>> kern :warn : [ 28.052350] [ T399] kasan_save_stack+0x1e/0x70
>>> kern :warn : [ 28.053001] [ T399] kasan_save_track+0x10/0x30
>>> kern :warn : [ 28.053646] [ T399] __kasan_kmalloc+0x8b/0xb0
>>> kern :warn : [ 28.054278] [ T399] __kmalloc_noprof+0x1d8/0x5f0
>>> kern :warn : [ 28.054944] [ T399] init_bdb_block+0x128/0xc30 [i915]
>>> kern :warn : [ 28.055915] [ T399] intel_bios_init+0x4de/0x14b0 [i915]
>>> kern :warn : [ 28.056854] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
>>> kern :warn : [ 28.057984] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
>>> kern :warn : [ 28.058917] [ T399] local_pci_probe+0xdb/0x1b0
>>> kern :warn : [ 28.059565] [ T399] pci_call_probe+0x153/0x4f0
>>> kern :warn : [ 28.060210] [ T399] pci_device_probe+0x173/0x2f0
>>> kern :warn : [ 28.060878] [ T399] call_driver_probe+0x62/0x1f0
>>> kern :warn : [ 28.061547] [ T399] really_probe+0x197/0x770
>>> kern :warn : [ 28.062168] [ T399] __driver_probe_device+0x18c/0x3b0
>>> kern :warn : [ 28.062894] [ T399] driver_probe_device+0x4a/0x130
>>> kern :warn : [ 28.063587] [ T399] __driver_attach+0x18c/0x4f0
>>> kern :warn : [ 28.064243] [ T399] bus_for_each_dev+0xef/0x170
>>> kern :warn : [ 28.064898] [ T399] bus_add_driver+0x2a7/0x4f0
>>> kern :warn : [ 28.065543] [ T399] driver_register+0x1a1/0x370
>>> kern :warn : [ 28.066202] [ T399] i915_init+0x57/0x160 [i915]
>>> kern :warn : [ 28.067030] [ T399] do_one_initcall+0x8d/0x3f0
>>> kern :warn : [ 28.067677] [ T399] do_init_module+0x281/0x830
>>> kern :warn : [ 28.068320] [ T399] load_module+0x173d/0x2070
>>> kern :warn : [ 28.068951] [ T399] init_module_from_file+0x157/0x1b0
>>> kern :warn : [ 28.069678] [ T399] idempotent_init_module+0x21c/0x770
>>> kern :warn : [ 28.070417] [ T399] __x64_sys_finit_module+0xca/0x170
>>> kern :warn : [ 28.071143] [ T399] do_syscall_64+0x108/0x5b0
>>> kern :warn : [ 28.071777] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>
>>> kern :err : [ 28.072915] [ T399] The buggy address belongs to the object at ffff8881eba2c000
>>> which belongs to the cache kmalloc-2k of size 2048
>>> kern :err : [ 28.074832] [ T399] The buggy address is located 0 bytes to the right of
>>> allocated 1181-byte region [ffff8881eba2c000, ffff8881eba2c49d)
>>
>>> kern :err : [ 28.077135] [ T399] The buggy address belongs to the physical page:
>>> kern :warn : [ 28.078017] [ T399] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eba28
>>> kern :warn : [ 28.079226] [ T399] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>>> kern :warn : [ 28.080389] [ T399] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
>>> kern :warn : [ 28.081460] [ T399] page_type: f5(slab)
>>> kern :warn : [ 28.082008] [ T399] raw: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
>>> kern :warn : [ 28.083180] [ T399] raw: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
>>> kern :warn : [ 28.084355] [ T399] head: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
>>> kern :warn : [ 28.085541] [ T399] head: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
>>> kern :warn : [ 28.086725] [ T399] head: 0017ffffc0000003 ffffea0007ae8a01 00000000ffffffff 00000000ffffffff
>>> kern :warn : [ 28.087909] [ T399] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
>>> kern :warn : [ 28.089093] [ T399] page dumped because: kasan: bad access detected
>>
>>> kern :err : [ 28.090297] [ T399] Memory state around the buggy address:
>>> kern :err : [ 28.091073] [ T399] ffff8881eba2c380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> kern :err : [ 28.092175] [ T399] ffff8881eba2c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> kern :err : [ 28.093276] [ T399] >ffff8881eba2c480: 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc fc
>>> kern :err : [ 28.094376] [ T399] ^
>>> kern :err : [ 28.095041] [ T399] ffff8881eba2c500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>> kern :err : [ 28.096145] [ T399] ffff8881eba2c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>> kern :err : [ 28.097247] [ T399] ==================================================================
>>> kern :warn : [ 28.098668] [ T399] Disabling lock debugging due to kernel taint
>
^ permalink raw reply
* Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
From: Oliver Sang @ 2026-04-16 7:40 UTC (permalink / raw)
To: Petr Vorel
Cc: Michał Grzelak, lkp, intel-gfx, Jani Nikula, oe-lkp,
intel-xe, ltp, linux-integrity, Mimi Zohar, oliver.sang
In-Reply-To: <20260416064051.GA281695@pevik>
hi, Petr,
On Thu, Apr 16, 2026 at 08:40:51AM +0200, Petr Vorel wrote:
> Hi all,
>
> [ Cc Mimi and linux-integrity ]
> > Hello,
>
> > kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_parse_vswing_preemph_snps" on:
>
> > commit: 07d1ee54da4966c1457602dc088a8a43b29254cb ("[PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default")
> > url: https://github.com/intel-lab-lkp/linux/commits/Micha-Grzelak/drm-i915-lt-align-xe3plpd-with-VS-PE-Override-layout/20260401-092928
> > base: https://gitlab.freedesktop.org/drm/i915/kernel.git for-linux-next
> > patch link: https://lore.kernel.org/all/20260331183332.1773886-16-michal.grzelak@intel.com/
> > patch subject: [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
>
> > in testcase: ltp
> > version:
> > with following parameters:
>
> > test: ima
>
>
>
> > config: x86_64-rhel-9.4-ltp
> > compiler: gcc-14
> > test machine: 22 threads 1 sockets Intel(R) Core(TM) Ultra 9 185H @ 4.5GHz (Meteor Lake) with 32G memory
>
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202604150702.d409a2b6-lkp@intel.com
>
>
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com
>
>
> > kern :err : [ 27.966990] [ T399] ==================================================================
> > kern :err : [ 27.968126] [ T399] BUG: KASAN: slab-out-of-bounds in parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> > kern :err : [ 27.969712] [ T399] Read of size 4 at addr ffff8881eba2c49d by task (udev-worker)/399
>
> > kern :err : [ 27.971135] [ T399] CPU: 4 UID: 0 PID: 399 Comm: (udev-worker) Tainted: G S 7.0.0-rc4-01496-g07d1ee54da49 #1 PREEMPT(lazy)
> > kern :err : [ 27.971139] [ T399] Tainted: [S]=CPU_OUT_OF_SPEC
> > kern :err : [ 27.971140] [ T399] Hardware name: ASUSTeK COMPUTER INC. NUC14RVS-B/NUC14RVSU9, BIOS RVMTL357.0047.2025.0108.1408 01/08/2025
> > kern :err : [ 27.971142] [ T399] Call Trace:
> > kern :err : [ 27.971144] [ T399] <TASK>
> > kern :err : [ 27.971145] [ T399] dump_stack_lvl+0x47/0x70
> > kern :err : [ 27.971152] [ T399] print_address_description+0x88/0x320
> > kern :err : [ 27.971156] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> > kern :err : [ 27.971355] [ T399] print_report+0x106/0x1f4
> > kern :err : [ 27.971357] [ T399] ? __virt_addr_valid+0xc4/0x230
> > kern :err : [ 27.971360] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> > kern :err : [ 27.971533] [ T399] kasan_report+0xb5/0xf0
> > kern :err : [ 27.971537] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> > kern :err : [ 27.971704] [ T399] parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> > kern :err : [ 27.971868] [ T399] intel_bios_init+0xcc1/0x14b0 [i915]
> > kern :err : [ 27.972042] [ T399] ? drm_vblank_init+0x147/0x330 [drm]
> > kern :err : [ 27.972105] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
> > kern :err : [ 27.972295] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
> > kern :err : [ 27.972445] [ T399] ? __pfx_mutex_lock+0x10/0x10
> > kern :err : [ 27.972450] [ T399] ? mutex_lock+0x91/0xf0
> > kern :err : [ 27.972451] [ T399] ? __pfx_i915_driver_probe+0x10/0x10 [i915]
> > kern :err : [ 27.972597] [ T399] ? drm_privacy_screen_get+0x2bf/0x370 [drm]
> > kern :err : [ 27.972628] [ T399] ? intel_display_driver_probe_defer+0x41/0x70 [i915]
> > kern :err : [ 27.972814] [ T399] ? i915_pci_probe+0x2ab/0x3b0 [i915]
> > kern :err : [ 27.972963] [ T399] ? __pfx_i915_pci_probe+0x10/0x10 [i915]
> > kern :err : [ 27.973110] [ T399] local_pci_probe+0xdb/0x1b0
> > kern :err : [ 27.973114] [ T399] pci_call_probe+0x153/0x4f0
> > kern :err : [ 27.973116] [ T399] ? __pfx_pci_call_probe+0x10/0x10
> > kern :err : [ 27.973117] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> > kern :err : [ 27.973119] [ T399] ? pci_assign_irq+0x80/0x2f0
> > kern :err : [ 27.973121] [ T399] ? pci_match_device+0x38d/0x6b0
> > kern :err : [ 27.973123] [ T399] ? kernfs_create_link+0x164/0x230
> > kern :err : [ 27.973127] [ T399] pci_device_probe+0x173/0x2f0
> > kern :err : [ 27.973128] [ T399] call_driver_probe+0x62/0x1f0
> > kern :err : [ 27.973132] [ T399] really_probe+0x197/0x770
> > kern :err : [ 27.973134] [ T399] __driver_probe_device+0x18c/0x3b0
> > kern :err : [ 27.973137] [ T399] driver_probe_device+0x4a/0x130
> > kern :err : [ 27.973139] [ T399] __driver_attach+0x18c/0x4f0
> > kern :err : [ 27.973141] [ T399] ? __pfx___driver_attach+0x10/0x10
> > kern :err : [ 27.973143] [ T399] bus_for_each_dev+0xef/0x170
> > kern :err : [ 27.973145] [ T399] ? kasan_unpoison+0x40/0x70
> > kern :err : [ 27.973147] [ T399] ? __pfx_bus_for_each_dev+0x10/0x10
> > kern :err : [ 27.973149] [ T399] ? __kasan_slab_alloc+0x2f/0x70
> > kern :err : [ 27.973152] [ T399] ? klist_add_tail+0x132/0x270
> > kern :err : [ 27.973154] [ T399] bus_add_driver+0x2a7/0x4f0
> > kern :err : [ 27.973156] [ T399] driver_register+0x1a1/0x370
> > kern :err : [ 27.973158] [ T399] i915_init+0x57/0x160 [i915]
> > kern :err : [ 27.973307] [ T399] ? __pfx_i915_init+0x10/0x10 [i915]
> > kern :err : [ 27.973453] [ T399] do_one_initcall+0x8d/0x3f0
> > kern :err : [ 27.973455] [ T399] ? __pfx_do_one_initcall+0x10/0x10
> > kern :err : [ 27.973457] [ T399] ? kasan_unpoison+0x3b/0x70
> > kern :err : [ 27.973458] [ T399] ? kasan_unpoison+0x40/0x70
> > kern :err : [ 27.973460] [ T399] do_init_module+0x281/0x830
> > kern :err : [ 27.973463] [ T399] ? __pfx_do_init_module+0x10/0x10
> > kern :err : [ 27.973464] [ T399] ? kfree+0x195/0x430
> > kern :err : [ 27.973467] [ T399] load_module+0x173d/0x2070
> > kern :err : [ 27.973469] [ T399] ? ima_post_read_file+0x18f/0x230
>
> I'm surprised, but indeed it's could be triggered by IMA.
>
> Looking at full dmesg [1] I'm surprised that this is triggered before tests are
> actually run and there is no IMA specific kernel command line parameter. That
> means that error is not related to any LTP test.
>
> Is it always reproducible or just a random glitch?
in our tests, it's quite persistent and clean on parent:
=========================================================================================
tbox_group/testcase/rootfs/kconfig/compiler/test:
igk-mtl-nuc02/ltp/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/ima
e3d53a63657f3213 07d1ee54da4966c1457602dc088
---------------- ---------------------------
fail:runs %reproduction fail:runs
| | |
:6 100% 6:6 dmesg.BUG:KASAN:slab-out-of-bounds_in_parse_vswing_preemph_snps
>
> ima_post_read_file() is a part of IMA core therefore issue might be not related
> to any config, but just FYI kernel config [2].
>
> Kind regards,
> Petr
>
> [1] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/kmsg.xz
> [2] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/config-7.0.0-rc4-01496-g07d1ee54da49
>
> > kern :err : [ 27.973474] [ T399] ? __pfx_load_module+0x10/0x10
> > kern :err : [ 27.973476] [ T399] ? security_kernel_post_read_file+0x35/0xf0
> > kern :err : [ 27.973479] [ T399] ? __pfx_kernel_read_file+0x10/0x10
> > kern :err : [ 27.973483] [ T399] ? __pfx_current_time+0x10/0x10
> > kern :err : [ 27.973486] [ T399] ? init_module_from_file+0x157/0x1b0
> > kern :err : [ 27.973487] [ T399] init_module_from_file+0x157/0x1b0
> > kern :err : [ 27.973489] [ T399] ? __pfx_init_module_from_file+0x10/0x10
> > kern :err : [ 27.973491] [ T399] ? touch_atime+0x1bc/0x4f0
> > kern :err : [ 27.973493] [ T399] ? _raw_spin_lock+0x80/0xf0
> > kern :err : [ 27.973494] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> > kern :err : [ 27.973496] [ T399] ? __pfx_filemap_read+0x10/0x10
> > kern :err : [ 27.973498] [ T399] ? do_sys_openat2+0xeb/0x170
> > kern :err : [ 27.973501] [ T399] idempotent_init_module+0x21c/0x770
> > kern :err : [ 27.973503] [ T399] ? __pfx_idempotent_init_module+0x10/0x10
> > kern :err : [ 27.973505] [ T399] ? fdget+0x54/0x3b0
> > kern :err : [ 27.973506] [ T399] ? security_capable+0x35/0xf0
> > kern :err : [ 27.973509] [ T399] __x64_sys_finit_module+0xca/0x170
> > kern :err : [ 27.973511] [ T399] do_syscall_64+0x108/0x5b0
> > kern :err : [ 27.973513] [ T399] ? vfs_read+0x3be/0x9b0
> > kern :err : [ 27.973514] [ T399] ? vfs_read+0x3be/0x9b0
> > kern :err : [ 27.973516] [ T399] ? __pfx_vfs_read+0x10/0x10
> > kern :err : [ 27.973517] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> > kern :err : [ 27.973519] [ T399] ? fdget+0x54/0x3b0
> > kern :err : [ 27.973520] [ T399] ? __pfx___seccomp_filter+0x10/0x10
> > kern :err : [ 27.973523] [ T399] ? __x64_sys_pread64+0x18d/0x1f0
> > kern :err : [ 27.973525] [ T399] ? __pfx___x64_sys_pread64+0x10/0x10
> > kern :err : [ 27.973526] [ T399] ? fdget+0x54/0x3b0
> > kern :err : [ 27.973528] [ T399] ? security_capable+0x35/0xf0
> > kern :err : [ 27.973530] [ T399] ? do_syscall_64+0x140/0x5b0
> > kern :err : [ 27.973531] [ T399] ? arch_exit_to_user_mode_prepare+0x9e/0xf0
> > kern :err : [ 27.973533] [ T399] ? do_syscall_64+0x140/0x5b0
> > kern :err : [ 27.973534] [ T399] ? __x64_sys_openat+0x104/0x1f0
> > kern :err : [ 27.973536] [ T399] ? __pfx___x64_sys_openat+0x10/0x10
> > kern :err : [ 27.973538] [ T399] ? do_syscall_64+0x140/0x5b0
> > kern :err : [ 27.973540] [ T399] ? do_syscall_64+0x140/0x5b0
> > kern :err : [ 27.973541] [ T399] ? irqentry_exit+0x76/0x4f0
> > kern :err : [ 27.973544] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > kern :err : [ 27.973546] [ T399] RIP: 0033:0x7f3689aa8779
> > kern :err : [ 27.973549] [ T399] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 67 76 0d 00 f7 d8 64 89 01 48
> > kern :err : [ 27.973551] [ T399] RSP: 002b:00007ffca3326338 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> > kern :err : [ 27.973555] [ T399] RAX: ffffffffffffffda RBX: 000055c94afdd3e0 RCX: 00007f3689aa8779
> > kern :err : [ 27.973556] [ T399] RDX: 0000000000000000 RSI: 00007f36882ae44d RDI: 0000000000000053
> > kern :err : [ 27.973557] [ T399] RBP: 0000000000000000 R08: 0000000000000000 R09: 000055c94af65b30
> > kern :err : [ 27.973558] [ T399] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f36882ae44d
> > kern :err : [ 27.973559] [ T399] R13: 0000000000020000 R14: 000055c94afb65f0 R15: 0000000000000000
> > kern :err : [ 27.973561] [ T399] </TASK>
>
> > kern :err : [ 28.051757] [ T399] Allocated by task 399:
> > kern :warn : [ 28.052350] [ T399] kasan_save_stack+0x1e/0x70
> > kern :warn : [ 28.053001] [ T399] kasan_save_track+0x10/0x30
> > kern :warn : [ 28.053646] [ T399] __kasan_kmalloc+0x8b/0xb0
> > kern :warn : [ 28.054278] [ T399] __kmalloc_noprof+0x1d8/0x5f0
> > kern :warn : [ 28.054944] [ T399] init_bdb_block+0x128/0xc30 [i915]
> > kern :warn : [ 28.055915] [ T399] intel_bios_init+0x4de/0x14b0 [i915]
> > kern :warn : [ 28.056854] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
> > kern :warn : [ 28.057984] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
> > kern :warn : [ 28.058917] [ T399] local_pci_probe+0xdb/0x1b0
> > kern :warn : [ 28.059565] [ T399] pci_call_probe+0x153/0x4f0
> > kern :warn : [ 28.060210] [ T399] pci_device_probe+0x173/0x2f0
> > kern :warn : [ 28.060878] [ T399] call_driver_probe+0x62/0x1f0
> > kern :warn : [ 28.061547] [ T399] really_probe+0x197/0x770
> > kern :warn : [ 28.062168] [ T399] __driver_probe_device+0x18c/0x3b0
> > kern :warn : [ 28.062894] [ T399] driver_probe_device+0x4a/0x130
> > kern :warn : [ 28.063587] [ T399] __driver_attach+0x18c/0x4f0
> > kern :warn : [ 28.064243] [ T399] bus_for_each_dev+0xef/0x170
> > kern :warn : [ 28.064898] [ T399] bus_add_driver+0x2a7/0x4f0
> > kern :warn : [ 28.065543] [ T399] driver_register+0x1a1/0x370
> > kern :warn : [ 28.066202] [ T399] i915_init+0x57/0x160 [i915]
> > kern :warn : [ 28.067030] [ T399] do_one_initcall+0x8d/0x3f0
> > kern :warn : [ 28.067677] [ T399] do_init_module+0x281/0x830
> > kern :warn : [ 28.068320] [ T399] load_module+0x173d/0x2070
> > kern :warn : [ 28.068951] [ T399] init_module_from_file+0x157/0x1b0
> > kern :warn : [ 28.069678] [ T399] idempotent_init_module+0x21c/0x770
> > kern :warn : [ 28.070417] [ T399] __x64_sys_finit_module+0xca/0x170
> > kern :warn : [ 28.071143] [ T399] do_syscall_64+0x108/0x5b0
> > kern :warn : [ 28.071777] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> > kern :err : [ 28.072915] [ T399] The buggy address belongs to the object at ffff8881eba2c000
> > which belongs to the cache kmalloc-2k of size 2048
> > kern :err : [ 28.074832] [ T399] The buggy address is located 0 bytes to the right of
> > allocated 1181-byte region [ffff8881eba2c000, ffff8881eba2c49d)
>
> > kern :err : [ 28.077135] [ T399] The buggy address belongs to the physical page:
> > kern :warn : [ 28.078017] [ T399] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eba28
> > kern :warn : [ 28.079226] [ T399] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> > kern :warn : [ 28.080389] [ T399] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
> > kern :warn : [ 28.081460] [ T399] page_type: f5(slab)
> > kern :warn : [ 28.082008] [ T399] raw: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
> > kern :warn : [ 28.083180] [ T399] raw: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
> > kern :warn : [ 28.084355] [ T399] head: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
> > kern :warn : [ 28.085541] [ T399] head: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
> > kern :warn : [ 28.086725] [ T399] head: 0017ffffc0000003 ffffea0007ae8a01 00000000ffffffff 00000000ffffffff
> > kern :warn : [ 28.087909] [ T399] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> > kern :warn : [ 28.089093] [ T399] page dumped because: kasan: bad access detected
>
> > kern :err : [ 28.090297] [ T399] Memory state around the buggy address:
> > kern :err : [ 28.091073] [ T399] ffff8881eba2c380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > kern :err : [ 28.092175] [ T399] ffff8881eba2c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > kern :err : [ 28.093276] [ T399] >ffff8881eba2c480: 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc fc
> > kern :err : [ 28.094376] [ T399] ^
> > kern :err : [ 28.095041] [ T399] ffff8881eba2c500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > kern :err : [ 28.096145] [ T399] ffff8881eba2c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > kern :err : [ 28.097247] [ T399] ==================================================================
> > kern :warn : [ 28.098668] [ T399] Disabling lock debugging due to kernel taint
^ permalink raw reply
* Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
From: Petr Vorel @ 2026-04-16 6:40 UTC (permalink / raw)
To: kernel test robot
Cc: Michał Grzelak, lkp, intel-gfx, Jani Nikula, oe-lkp,
intel-xe, ltp, linux-integrity, Mimi Zohar
In-Reply-To: <202604150702.d409a2b6-lkp@intel.com>
Hi all,
[ Cc Mimi and linux-integrity ]
> Hello,
> kernel test robot noticed "BUG:KASAN:slab-out-of-bounds_in_parse_vswing_preemph_snps" on:
> commit: 07d1ee54da4966c1457602dc088a8a43b29254cb ("[PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default")
> url: https://github.com/intel-lab-lkp/linux/commits/Micha-Grzelak/drm-i915-lt-align-xe3plpd-with-VS-PE-Override-layout/20260401-092928
> base: https://gitlab.freedesktop.org/drm/i915/kernel.git for-linux-next
> patch link: https://lore.kernel.org/all/20260331183332.1773886-16-michal.grzelak@intel.com/
> patch subject: [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
> in testcase: ltp
> version:
> with following parameters:
> test: ima
> config: x86_64-rhel-9.4-ltp
> compiler: gcc-14
> test machine: 22 threads 1 sockets Intel(R) Core(TM) Ultra 9 185H @ 4.5GHz (Meteor Lake) with 32G memory
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202604150702.d409a2b6-lkp@intel.com
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com
> kern :err : [ 27.966990] [ T399] ==================================================================
> kern :err : [ 27.968126] [ T399] BUG: KASAN: slab-out-of-bounds in parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.969712] [ T399] Read of size 4 at addr ffff8881eba2c49d by task (udev-worker)/399
> kern :err : [ 27.971135] [ T399] CPU: 4 UID: 0 PID: 399 Comm: (udev-worker) Tainted: G S 7.0.0-rc4-01496-g07d1ee54da49 #1 PREEMPT(lazy)
> kern :err : [ 27.971139] [ T399] Tainted: [S]=CPU_OUT_OF_SPEC
> kern :err : [ 27.971140] [ T399] Hardware name: ASUSTeK COMPUTER INC. NUC14RVS-B/NUC14RVSU9, BIOS RVMTL357.0047.2025.0108.1408 01/08/2025
> kern :err : [ 27.971142] [ T399] Call Trace:
> kern :err : [ 27.971144] [ T399] <TASK>
> kern :err : [ 27.971145] [ T399] dump_stack_lvl+0x47/0x70
> kern :err : [ 27.971152] [ T399] print_address_description+0x88/0x320
> kern :err : [ 27.971156] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971355] [ T399] print_report+0x106/0x1f4
> kern :err : [ 27.971357] [ T399] ? __virt_addr_valid+0xc4/0x230
> kern :err : [ 27.971360] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971533] [ T399] kasan_report+0xb5/0xf0
> kern :err : [ 27.971537] [ T399] ? parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971704] [ T399] parse_vswing_preemph_snps+0x2dd/0x430 [i915]
> kern :err : [ 27.971868] [ T399] intel_bios_init+0xcc1/0x14b0 [i915]
> kern :err : [ 27.972042] [ T399] ? drm_vblank_init+0x147/0x330 [drm]
> kern :err : [ 27.972105] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
> kern :err : [ 27.972295] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
> kern :err : [ 27.972445] [ T399] ? __pfx_mutex_lock+0x10/0x10
> kern :err : [ 27.972450] [ T399] ? mutex_lock+0x91/0xf0
> kern :err : [ 27.972451] [ T399] ? __pfx_i915_driver_probe+0x10/0x10 [i915]
> kern :err : [ 27.972597] [ T399] ? drm_privacy_screen_get+0x2bf/0x370 [drm]
> kern :err : [ 27.972628] [ T399] ? intel_display_driver_probe_defer+0x41/0x70 [i915]
> kern :err : [ 27.972814] [ T399] ? i915_pci_probe+0x2ab/0x3b0 [i915]
> kern :err : [ 27.972963] [ T399] ? __pfx_i915_pci_probe+0x10/0x10 [i915]
> kern :err : [ 27.973110] [ T399] local_pci_probe+0xdb/0x1b0
> kern :err : [ 27.973114] [ T399] pci_call_probe+0x153/0x4f0
> kern :err : [ 27.973116] [ T399] ? __pfx_pci_call_probe+0x10/0x10
> kern :err : [ 27.973117] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> kern :err : [ 27.973119] [ T399] ? pci_assign_irq+0x80/0x2f0
> kern :err : [ 27.973121] [ T399] ? pci_match_device+0x38d/0x6b0
> kern :err : [ 27.973123] [ T399] ? kernfs_create_link+0x164/0x230
> kern :err : [ 27.973127] [ T399] pci_device_probe+0x173/0x2f0
> kern :err : [ 27.973128] [ T399] call_driver_probe+0x62/0x1f0
> kern :err : [ 27.973132] [ T399] really_probe+0x197/0x770
> kern :err : [ 27.973134] [ T399] __driver_probe_device+0x18c/0x3b0
> kern :err : [ 27.973137] [ T399] driver_probe_device+0x4a/0x130
> kern :err : [ 27.973139] [ T399] __driver_attach+0x18c/0x4f0
> kern :err : [ 27.973141] [ T399] ? __pfx___driver_attach+0x10/0x10
> kern :err : [ 27.973143] [ T399] bus_for_each_dev+0xef/0x170
> kern :err : [ 27.973145] [ T399] ? kasan_unpoison+0x40/0x70
> kern :err : [ 27.973147] [ T399] ? __pfx_bus_for_each_dev+0x10/0x10
> kern :err : [ 27.973149] [ T399] ? __kasan_slab_alloc+0x2f/0x70
> kern :err : [ 27.973152] [ T399] ? klist_add_tail+0x132/0x270
> kern :err : [ 27.973154] [ T399] bus_add_driver+0x2a7/0x4f0
> kern :err : [ 27.973156] [ T399] driver_register+0x1a1/0x370
> kern :err : [ 27.973158] [ T399] i915_init+0x57/0x160 [i915]
> kern :err : [ 27.973307] [ T399] ? __pfx_i915_init+0x10/0x10 [i915]
> kern :err : [ 27.973453] [ T399] do_one_initcall+0x8d/0x3f0
> kern :err : [ 27.973455] [ T399] ? __pfx_do_one_initcall+0x10/0x10
> kern :err : [ 27.973457] [ T399] ? kasan_unpoison+0x3b/0x70
> kern :err : [ 27.973458] [ T399] ? kasan_unpoison+0x40/0x70
> kern :err : [ 27.973460] [ T399] do_init_module+0x281/0x830
> kern :err : [ 27.973463] [ T399] ? __pfx_do_init_module+0x10/0x10
> kern :err : [ 27.973464] [ T399] ? kfree+0x195/0x430
> kern :err : [ 27.973467] [ T399] load_module+0x173d/0x2070
> kern :err : [ 27.973469] [ T399] ? ima_post_read_file+0x18f/0x230
I'm surprised, but indeed it's could be triggered by IMA.
Looking at full dmesg [1] I'm surprised that this is triggered before tests are
actually run and there is no IMA specific kernel command line parameter. That
means that error is not related to any LTP test.
Is it always reproducible or just a random glitch?
ima_post_read_file() is a part of IMA core therefore issue might be not related
to any config, but just FYI kernel config [2].
Kind regards,
Petr
[1] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/kmsg.xz
[2] https://download.01.org/0day-ci/archive/20260415/202604150702.d409a2b6-lkp@intel.com/config-7.0.0-rc4-01496-g07d1ee54da49
> kern :err : [ 27.973474] [ T399] ? __pfx_load_module+0x10/0x10
> kern :err : [ 27.973476] [ T399] ? security_kernel_post_read_file+0x35/0xf0
> kern :err : [ 27.973479] [ T399] ? __pfx_kernel_read_file+0x10/0x10
> kern :err : [ 27.973483] [ T399] ? __pfx_current_time+0x10/0x10
> kern :err : [ 27.973486] [ T399] ? init_module_from_file+0x157/0x1b0
> kern :err : [ 27.973487] [ T399] init_module_from_file+0x157/0x1b0
> kern :err : [ 27.973489] [ T399] ? __pfx_init_module_from_file+0x10/0x10
> kern :err : [ 27.973491] [ T399] ? touch_atime+0x1bc/0x4f0
> kern :err : [ 27.973493] [ T399] ? _raw_spin_lock+0x80/0xf0
> kern :err : [ 27.973494] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> kern :err : [ 27.973496] [ T399] ? __pfx_filemap_read+0x10/0x10
> kern :err : [ 27.973498] [ T399] ? do_sys_openat2+0xeb/0x170
> kern :err : [ 27.973501] [ T399] idempotent_init_module+0x21c/0x770
> kern :err : [ 27.973503] [ T399] ? __pfx_idempotent_init_module+0x10/0x10
> kern :err : [ 27.973505] [ T399] ? fdget+0x54/0x3b0
> kern :err : [ 27.973506] [ T399] ? security_capable+0x35/0xf0
> kern :err : [ 27.973509] [ T399] __x64_sys_finit_module+0xca/0x170
> kern :err : [ 27.973511] [ T399] do_syscall_64+0x108/0x5b0
> kern :err : [ 27.973513] [ T399] ? vfs_read+0x3be/0x9b0
> kern :err : [ 27.973514] [ T399] ? vfs_read+0x3be/0x9b0
> kern :err : [ 27.973516] [ T399] ? __pfx_vfs_read+0x10/0x10
> kern :err : [ 27.973517] [ T399] ? __pfx__raw_spin_lock+0x10/0x10
> kern :err : [ 27.973519] [ T399] ? fdget+0x54/0x3b0
> kern :err : [ 27.973520] [ T399] ? __pfx___seccomp_filter+0x10/0x10
> kern :err : [ 27.973523] [ T399] ? __x64_sys_pread64+0x18d/0x1f0
> kern :err : [ 27.973525] [ T399] ? __pfx___x64_sys_pread64+0x10/0x10
> kern :err : [ 27.973526] [ T399] ? fdget+0x54/0x3b0
> kern :err : [ 27.973528] [ T399] ? security_capable+0x35/0xf0
> kern :err : [ 27.973530] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973531] [ T399] ? arch_exit_to_user_mode_prepare+0x9e/0xf0
> kern :err : [ 27.973533] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973534] [ T399] ? __x64_sys_openat+0x104/0x1f0
> kern :err : [ 27.973536] [ T399] ? __pfx___x64_sys_openat+0x10/0x10
> kern :err : [ 27.973538] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973540] [ T399] ? do_syscall_64+0x140/0x5b0
> kern :err : [ 27.973541] [ T399] ? irqentry_exit+0x76/0x4f0
> kern :err : [ 27.973544] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> kern :err : [ 27.973546] [ T399] RIP: 0033:0x7f3689aa8779
> kern :err : [ 27.973549] [ T399] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 67 76 0d 00 f7 d8 64 89 01 48
> kern :err : [ 27.973551] [ T399] RSP: 002b:00007ffca3326338 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> kern :err : [ 27.973555] [ T399] RAX: ffffffffffffffda RBX: 000055c94afdd3e0 RCX: 00007f3689aa8779
> kern :err : [ 27.973556] [ T399] RDX: 0000000000000000 RSI: 00007f36882ae44d RDI: 0000000000000053
> kern :err : [ 27.973557] [ T399] RBP: 0000000000000000 R08: 0000000000000000 R09: 000055c94af65b30
> kern :err : [ 27.973558] [ T399] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f36882ae44d
> kern :err : [ 27.973559] [ T399] R13: 0000000000020000 R14: 000055c94afb65f0 R15: 0000000000000000
> kern :err : [ 27.973561] [ T399] </TASK>
> kern :err : [ 28.051757] [ T399] Allocated by task 399:
> kern :warn : [ 28.052350] [ T399] kasan_save_stack+0x1e/0x70
> kern :warn : [ 28.053001] [ T399] kasan_save_track+0x10/0x30
> kern :warn : [ 28.053646] [ T399] __kasan_kmalloc+0x8b/0xb0
> kern :warn : [ 28.054278] [ T399] __kmalloc_noprof+0x1d8/0x5f0
> kern :warn : [ 28.054944] [ T399] init_bdb_block+0x128/0xc30 [i915]
> kern :warn : [ 28.055915] [ T399] intel_bios_init+0x4de/0x14b0 [i915]
> kern :warn : [ 28.056854] [ T399] intel_display_driver_probe_noirq+0x8d/0x870 [i915]
> kern :warn : [ 28.057984] [ T399] i915_driver_probe+0x209/0x9f0 [i915]
> kern :warn : [ 28.058917] [ T399] local_pci_probe+0xdb/0x1b0
> kern :warn : [ 28.059565] [ T399] pci_call_probe+0x153/0x4f0
> kern :warn : [ 28.060210] [ T399] pci_device_probe+0x173/0x2f0
> kern :warn : [ 28.060878] [ T399] call_driver_probe+0x62/0x1f0
> kern :warn : [ 28.061547] [ T399] really_probe+0x197/0x770
> kern :warn : [ 28.062168] [ T399] __driver_probe_device+0x18c/0x3b0
> kern :warn : [ 28.062894] [ T399] driver_probe_device+0x4a/0x130
> kern :warn : [ 28.063587] [ T399] __driver_attach+0x18c/0x4f0
> kern :warn : [ 28.064243] [ T399] bus_for_each_dev+0xef/0x170
> kern :warn : [ 28.064898] [ T399] bus_add_driver+0x2a7/0x4f0
> kern :warn : [ 28.065543] [ T399] driver_register+0x1a1/0x370
> kern :warn : [ 28.066202] [ T399] i915_init+0x57/0x160 [i915]
> kern :warn : [ 28.067030] [ T399] do_one_initcall+0x8d/0x3f0
> kern :warn : [ 28.067677] [ T399] do_init_module+0x281/0x830
> kern :warn : [ 28.068320] [ T399] load_module+0x173d/0x2070
> kern :warn : [ 28.068951] [ T399] init_module_from_file+0x157/0x1b0
> kern :warn : [ 28.069678] [ T399] idempotent_init_module+0x21c/0x770
> kern :warn : [ 28.070417] [ T399] __x64_sys_finit_module+0xca/0x170
> kern :warn : [ 28.071143] [ T399] do_syscall_64+0x108/0x5b0
> kern :warn : [ 28.071777] [ T399] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> kern :err : [ 28.072915] [ T399] The buggy address belongs to the object at ffff8881eba2c000
> which belongs to the cache kmalloc-2k of size 2048
> kern :err : [ 28.074832] [ T399] The buggy address is located 0 bytes to the right of
> allocated 1181-byte region [ffff8881eba2c000, ffff8881eba2c49d)
> kern :err : [ 28.077135] [ T399] The buggy address belongs to the physical page:
> kern :warn : [ 28.078017] [ T399] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eba28
> kern :warn : [ 28.079226] [ T399] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> kern :warn : [ 28.080389] [ T399] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
> kern :warn : [ 28.081460] [ T399] page_type: f5(slab)
> kern :warn : [ 28.082008] [ T399] raw: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
> kern :warn : [ 28.083180] [ T399] raw: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
> kern :warn : [ 28.084355] [ T399] head: 0017ffffc0000040 ffff888100042f00 dead000000000100 dead000000000122
> kern :warn : [ 28.085541] [ T399] head: 0000000000000000 0000000800080008 00000000f5000000 0000000000000000
> kern :warn : [ 28.086725] [ T399] head: 0017ffffc0000003 ffffea0007ae8a01 00000000ffffffff 00000000ffffffff
> kern :warn : [ 28.087909] [ T399] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
> kern :warn : [ 28.089093] [ T399] page dumped because: kasan: bad access detected
> kern :err : [ 28.090297] [ T399] Memory state around the buggy address:
> kern :err : [ 28.091073] [ T399] ffff8881eba2c380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> kern :err : [ 28.092175] [ T399] ffff8881eba2c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> kern :err : [ 28.093276] [ T399] >ffff8881eba2c480: 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc fc
> kern :err : [ 28.094376] [ T399] ^
> kern :err : [ 28.095041] [ T399] ffff8881eba2c500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> kern :err : [ 28.096145] [ T399] ffff8881eba2c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> kern :err : [ 28.097247] [ T399] ==================================================================
> kern :warn : [ 28.098668] [ T399] Disabling lock debugging due to kernel taint
^ permalink raw reply
* Re: [PATCH v4] KEYS: trusted: Debugging as a feature
From: Nayna Jain @ 2026-04-16 3:16 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-integrity
Cc: Srish Srinivasan, Jonathan Corbet, Shuah Khan, James Bottomley,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Ahmad Fatoum, Pengutronix Kernel Team,
Andrew Morton, Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Pawan Gupta, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Li RongQing, Paul E. McKenney, Thomas Gleixner, Bjorn Helgaas,
linux-doc, linux-kernel, keyrings, linux-security-module
In-Reply-To: <20260415111202.63888-1-jarkko@kernel.org>
On 4/15/26 7:12 AM, Jarkko Sakkinen wrote:
> TPM_DEBUG, and other similar flags, are a non-standard way to specify a
> feature in Linux kernel. Introduce CONFIG_TRUSTED_KEYS_DEBUG for trusted
> keys, and use it to replace these ad-hoc feature flags.
>
> Given that trusted keys debug dumps can contain sensitive data, harden the
> feature as follows:
>
> 1. In the Kconfig description postulate that pr_debug() statements must be
> used.
> 2. Use pr_debug() statements in TPM 1.x driver to print the protocol dump.
> 3. Require trusted.debug=1 on the kernel command line (default: 0) to
> activate dumps at runtime, even when CONFIG_TRUSTED_KEYS_DEBUG=y.
>
> Traces, when actually needed, can be easily enabled by providing
> trusted.dyndbg='+p' and trusted.debug=1 in the kernel command-line.
Thanks for adding the documentation.
Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
>
> Reported-by: Nayna Jain <nayna@linux.ibm.com>
> Closes: https://lore.kernel.org/all/7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com/
> Reviewed-by: Nayna Jain <nayna@linux.ibm.com>
> Tested-by: Srish Srinivasan <ssrish@linux.ibm.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
> v4:
> - Added kernel parameter documentation.t
> - Added tags from Srishand and Nayna.
> - Sanity check round. This version will be applied unless there is
> something specific to address.
> v3:
> - Add kernel-command line option for enabling the traces.
> - Add safety information to the Kconfig entry.
> v2:
> - Implement for all trusted keys backends.
> - Add HAVE_TRUSTED_KEYS_DEBUG as it is a good practice despite full
> coverage.
> ---
> .../admin-guide/kernel-parameters.txt | 16 +++++++
> include/keys/trusted-type.h | 21 +++++----
> security/keys/trusted-keys/Kconfig | 23 ++++++++++
> security/keys/trusted-keys/trusted_caam.c | 7 ++-
> security/keys/trusted-keys/trusted_core.c | 6 +++
> security/keys/trusted-keys/trusted_tpm1.c | 44 +++++++++++--------
> 6 files changed, 87 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index f2ce1f4975c1..f1515668c8ab 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7917,6 +7917,22 @@ Kernel parameters
> first trust source as a backend which is initialized
> successfully during iteration.
>
> + trusted.debug= [KEYS]
> + Format: <bool>
> + Enable trusted keys debug traces at runtime when
> + CONFIG_TRUSTED_KEYS_DEBUG=y.
> +
> + To make the traces visible after enabling the option,
> + use trusted.dyndbg='+p' as needed. By convention,
> + the subsystem uses pr_debug() for these traces.
> +
> + SAFETY: The traces can leak sensitive data, so be
> + cautious before enabling this. They remain inactive
> + unless this parameter is set this option to a true
> + value.
> +
> + Default: false
> +
> trusted.rng= [KEYS]
> Format: <string>
> The RNG used to generate key material for trusted keys.
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 03527162613f..9f9940482da4 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -83,18 +83,21 @@ struct trusted_key_source {
>
> extern struct key_type key_type_trusted;
>
> -#define TRUSTED_DEBUG 0
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> +extern bool trusted_debug;
>
> -#if TRUSTED_DEBUG
> static inline void dump_payload(struct trusted_key_payload *p)
> {
> - pr_info("key_len %d\n", p->key_len);
> - print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> - 16, 1, p->key, p->key_len, 0);
> - pr_info("bloblen %d\n", p->blob_len);
> - print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> - 16, 1, p->blob, p->blob_len, 0);
> - pr_info("migratable %d\n", p->migratable);
> + if (!trusted_debug)
> + return;
> +
> + pr_debug("key_len %d\n", p->key_len);
> + print_hex_dump_debug("key ", DUMP_PREFIX_NONE,
> + 16, 1, p->key, p->key_len, 0);
> + pr_debug("bloblen %d\n", p->blob_len);
> + print_hex_dump_debug("blob ", DUMP_PREFIX_NONE,
> + 16, 1, p->blob, p->blob_len, 0);
> + pr_debug("migratable %d\n", p->migratable);
> }
> #else
> static inline void dump_payload(struct trusted_key_payload *p)
> diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
> index 9e00482d886a..e5a4a53aeab2 100644
> --- a/security/keys/trusted-keys/Kconfig
> +++ b/security/keys/trusted-keys/Kconfig
> @@ -1,10 +1,29 @@
> config HAVE_TRUSTED_KEYS
> bool
>
> +config HAVE_TRUSTED_KEYS_DEBUG
> + bool
> +
> +config TRUSTED_KEYS_DEBUG
> + bool "Debug trusted keys"
> + depends on HAVE_TRUSTED_KEYS_DEBUG
> + default n
> + help
> + Trusted key backends and core code that support debug traces can
> + opt-in that feature here. Traces must only use debug level output, as
> + sensitive data may pass by. In the kernel-command line traces can be
> + enabled via trusted.dyndbg='+p'.
> +
> + SAFETY: Debug dumps are inactive at runtime until trusted.debug is set
> + to a true value on the kernel command-line. Use at your utmost
> + consideration when enabling this feature on a production build. The
> + general advice is not to do this.
> +
> config TRUSTED_KEYS_TPM
> bool "TPM-based trusted keys"
> depends on TCG_TPM >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select CRYPTO_HASH_INFO
> select CRYPTO_LIB_SHA1
> select CRYPTO_LIB_UTILS
> @@ -23,6 +42,7 @@ config TRUSTED_KEYS_TEE
> bool "TEE-based trusted keys"
> depends on TEE >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of the Trusted Execution Environment (TEE) as trusted
> @@ -33,6 +53,7 @@ config TRUSTED_KEYS_CAAM
> depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
> select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of NXP's Cryptographic Accelerator and Assurance Module
> @@ -42,6 +63,7 @@ config TRUSTED_KEYS_DCP
> bool "DCP-based trusted keys"
> depends on CRYPTO_DEV_MXS_DCP >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of NXP's DCP (Data Co-Processor) as trusted key backend.
> @@ -50,6 +72,7 @@ config TRUSTED_KEYS_PKWM
> bool "PKWM-based trusted keys"
> depends on PSERIES_PLPKS >= TRUSTED_KEYS
> default y
> + select HAVE_TRUSTED_KEYS_DEBUG
> select HAVE_TRUSTED_KEYS
> help
> Enable use of IBM PowerVM Key Wrapping Module (PKWM) as a trusted key backend.
> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> index 601943ce0d60..6a33dbf2a7f5 100644
> --- a/security/keys/trusted-keys/trusted_caam.c
> +++ b/security/keys/trusted-keys/trusted_caam.c
> @@ -28,10 +28,13 @@ static const match_table_t key_tokens = {
> {opt_err, NULL}
> };
>
> -#ifdef CAAM_DEBUG
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> static inline void dump_options(const struct caam_pkey_info *pkey_info)
> {
> - pr_info("key encryption algo %d\n", pkey_info->key_enc_algo);
> + if (!trusted_debug)
> + return;
> +
> + pr_debug("key encryption algo %d\n", pkey_info->key_enc_algo);
> }
> #else
> static inline void dump_options(const struct caam_pkey_info *pkey_info)
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 0b142d941cd2..6aed17bee09d 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -31,6 +31,12 @@ static char *trusted_rng = "default";
> module_param_named(rng, trusted_rng, charp, 0);
> MODULE_PARM_DESC(rng, "Select trusted key RNG");
>
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> +bool trusted_debug;
> +module_param_named(debug, trusted_debug, bool, 0);
> +MODULE_PARM_DESC(debug, "Enable trusted keys debug traces (default: 0)");
> +#endif
> +
> static char *trusted_key_source;
> module_param_named(source, trusted_key_source, charp, 0);
> MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee, caam, dcp or pkwm)");
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 6ea728f1eae6..13513819991e 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -46,38 +46,44 @@ enum {
> SRK_keytype = 4
> };
>
> -#define TPM_DEBUG 0
> -
> -#if TPM_DEBUG
> +#ifdef CONFIG_TRUSTED_KEYS_DEBUG
> static inline void dump_options(struct trusted_key_options *o)
> {
> - pr_info("sealing key type %d\n", o->keytype);
> - pr_info("sealing key handle %0X\n", o->keyhandle);
> - pr_info("pcrlock %d\n", o->pcrlock);
> - pr_info("pcrinfo %d\n", o->pcrinfo_len);
> - print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
> - 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> + if (!trusted_debug)
> + return;
> +
> + pr_debug("sealing key type %d\n", o->keytype);
> + pr_debug("sealing key handle %0X\n", o->keyhandle);
> + pr_debug("pcrlock %d\n", o->pcrlock);
> + pr_debug("pcrinfo %d\n", o->pcrinfo_len);
> + print_hex_dump_debug("pcrinfo ", DUMP_PREFIX_NONE,
> + 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> }
>
> static inline void dump_sess(struct osapsess *s)
> {
> - print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> - 16, 1, &s->handle, 4, 0);
> - pr_info("secret:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> - 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> - pr_info("trusted-key: enonce:\n");
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> - 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> + if (!trusted_debug)
> + return;
> +
> + print_hex_dump_debug("trusted-key: handle ", DUMP_PREFIX_NONE,
> + 16, 1, &s->handle, 4, 0);
> + pr_debug("secret:\n");
> + print_hex_dump_debug("", DUMP_PREFIX_NONE,
> + 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> + pr_debug("trusted-key: enonce:\n");
> + print_hex_dump_debug("", DUMP_PREFIX_NONE,
> + 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> }
>
> static inline void dump_tpm_buf(unsigned char *buf)
> {
> int len;
>
> - pr_info("\ntpm buffer\n");
> + if (!trusted_debug)
> + return;
> + pr_debug("\ntpm buffer\n");
> len = LOAD32(buf, TPM_SIZE_OFFSET);
> - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> + print_hex_dump_debug("", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> }
> #else
> static inline void dump_options(struct trusted_key_options *o)
^ permalink raw reply
* Re: [PATCH v2] trusted-keys: move pr_fmt out of trusted-type.h
From: Marco Felsch @ 2026-04-15 20:50 UTC (permalink / raw)
To: Josh Snyder
Cc: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Ahmad Fatoum, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg, linux-security-module,
linux-integrity, keyrings, linux-kernel
In-Reply-To: <20260415-trusted-key-header-v2-1-5244f9ef0d09@code406.com>
On 26-04-15, Josh Snyder wrote:
> Defining pr_fmt in a widely-included header leaks the "trusted_key: "
> prefix into every translation unit that transitively includes
> <keys/trusted-type.h>. dm-crypt, for example, ends up printing
>
> trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
>
> dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
> ("dm crypt: support using trusted keys"), which predates the pr_fmt
> addition, so the regression has been live from the moment the header
> gained its own pr_fmt definition.
>
> Move the pr_fmt definition into the trusted-keys source files that
> actually want the prefix, with specific prefixes for each key type.
>
> Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Josh Snyder <josh@code406.com>
> ---
> Changes in v2:
> - specific pr_fmt based on trusted key type
> ---
> include/keys/trusted-type.h | 6 ------
> security/keys/trusted-keys/trusted_caam.c | 2 ++
> security/keys/trusted-keys/trusted_core.c | 2 ++
> security/keys/trusted-keys/trusted_dcp.c | 2 ++
> security/keys/trusted-keys/trusted_pkwm.c | 2 ++
> security/keys/trusted-keys/trusted_tpm1.c | 2 ++
> security/keys/trusted-keys/trusted_tpm2.c | 2 ++
You missed the trusted_tee.c, sorry for not spotting this earlier.
Regards,
Marco
> 7 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 03527162613f7..54da1f174aeab 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -11,12 +11,6 @@
> #include <linux/rcupdate.h>
> #include <linux/tpm.h>
>
> -#ifdef pr_fmt
> -#undef pr_fmt
> -#endif
> -
> -#define pr_fmt(fmt) "trusted_key: " fmt
> -
> #define MIN_KEY_SIZE 32
> #define MAX_KEY_SIZE 128
> #if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
> index 601943ce0d60f..71c173bb2f727 100644
> --- a/security/keys/trusted-keys/trusted_caam.c
> +++ b/security/keys/trusted-keys/trusted_caam.c
> @@ -4,6 +4,8 @@
> * Copyright 2025 NXP
> */
>
> +#define pr_fmt(fmt) "trusted_key: caam: " fmt
> +
> #include <keys/trusted_caam.h>
> #include <keys/trusted-type.h>
> #include <linux/build_bug.h>
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 0b142d941cd2e..159af9dcfc774 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -6,6 +6,8 @@
> * See Documentation/security/keys/trusted-encrypted.rst
> */
>
> +#define pr_fmt(fmt) "trusted_key: " fmt
> +
> #include <keys/user-type.h>
> #include <keys/trusted-type.h>
> #include <keys/trusted_tee.h>
> diff --git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
> index 7b6eb655df0cb..41a23e2f30891 100644
> --- a/security/keys/trusted-keys/trusted_dcp.c
> +++ b/security/keys/trusted-keys/trusted_dcp.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2021 sigma star gmbh
> */
>
> +#define pr_fmt(fmt) "trusted_key: dcp: " fmt
> +
> #include <crypto/aead.h>
> #include <crypto/aes.h>
> #include <crypto/algapi.h>
> diff --git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
> index bf42c6679245a..108db105b639f 100644
> --- a/security/keys/trusted-keys/trusted_pkwm.c
> +++ b/security/keys/trusted-keys/trusted_pkwm.c
> @@ -3,6 +3,8 @@
> * Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
> */
>
> +#define pr_fmt(fmt) "trusted_key: pwkm: " fmt
> +
> #include <keys/trusted_pkwm.h>
> #include <keys/trusted-type.h>
> #include <linux/build_bug.h>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 6ea728f1eae6f..207be849796ed 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -6,6 +6,8 @@
> * See Documentation/security/keys/trusted-encrypted.rst
> */
>
> +#define pr_fmt(fmt) "trusted_key: tpm1: " fmt
> +
> #include <crypto/hash_info.h>
> #include <crypto/sha1.h>
> #include <crypto/utils.h>
> diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> index 6340823f8b53c..2a540b1af0b33 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -4,6 +4,8 @@
> * Copyright (C) 2014 Intel Corporation
> */
>
> +#define pr_fmt(fmt) "trusted_key: tpm2: " fmt
> +
> #include <linux/asn1_encoder.h>
> #include <linux/oid_registry.h>
> #include <linux/string.h>
>
> ---
> base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
> change-id: 20260411-trusted-key-header-a544a4f149d2
>
> Best regards,
> --
> Josh
>
>
>
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* [PATCH v2] trusted-keys: move pr_fmt out of trusted-type.h
From: Josh Snyder @ 2026-04-15 20:40 UTC (permalink / raw)
To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
Ahmad Fatoum, Pengutronix Kernel Team, Paul Moore, James Morris,
Serge E. Hallyn, David Gstir, sigma star Kernel Team,
Srish Srinivasan, Nayna Jain, Sumit Garg
Cc: linux-integrity, keyrings, linux-kernel, linux-security-module,
Josh Snyder
Defining pr_fmt in a widely-included header leaks the "trusted_key: "
prefix into every translation unit that transitively includes
<keys/trusted-type.h>. dm-crypt, for example, ends up printing
trusted_key: device-mapper: crypt: dm-10: INTEGRITY AEAD ERROR ...
dm-crypt began including <keys/trusted-type.h> in commit 363880c4eb36
("dm crypt: support using trusted keys"), which predates the pr_fmt
addition, so the regression has been live from the moment the header
gained its own pr_fmt definition.
Move the pr_fmt definition into the trusted-keys source files that
actually want the prefix, with specific prefixes for each key type.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Josh Snyder <josh@code406.com>
---
Changes in v2:
- specific pr_fmt based on trusted key type
---
| 6 ------
| 2 ++
| 2 ++
| 2 ++
| 2 ++
| 2 ++
| 2 ++
7 files changed, 12 insertions(+), 6 deletions(-)
--git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 03527162613f7..54da1f174aeab 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -11,12 +11,6 @@
#include <linux/rcupdate.h>
#include <linux/tpm.h>
-#ifdef pr_fmt
-#undef pr_fmt
-#endif
-
-#define pr_fmt(fmt) "trusted_key: " fmt
-
#define MIN_KEY_SIZE 32
#define MAX_KEY_SIZE 128
#if IS_ENABLED(CONFIG_TRUSTED_KEYS_PKWM)
--git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
index 601943ce0d60f..71c173bb2f727 100644
--- a/security/keys/trusted-keys/trusted_caam.c
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -4,6 +4,8 @@
* Copyright 2025 NXP
*/
+#define pr_fmt(fmt) "trusted_key: caam: " fmt
+
#include <keys/trusted_caam.h>
#include <keys/trusted-type.h>
#include <linux/build_bug.h>
--git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0b142d941cd2e..159af9dcfc774 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -6,6 +6,8 @@
* See Documentation/security/keys/trusted-encrypted.rst
*/
+#define pr_fmt(fmt) "trusted_key: " fmt
+
#include <keys/user-type.h>
#include <keys/trusted-type.h>
#include <keys/trusted_tee.h>
--git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c
index 7b6eb655df0cb..41a23e2f30891 100644
--- a/security/keys/trusted-keys/trusted_dcp.c
+++ b/security/keys/trusted-keys/trusted_dcp.c
@@ -3,6 +3,8 @@
* Copyright (C) 2021 sigma star gmbh
*/
+#define pr_fmt(fmt) "trusted_key: dcp: " fmt
+
#include <crypto/aead.h>
#include <crypto/aes.h>
#include <crypto/algapi.h>
--git a/security/keys/trusted-keys/trusted_pkwm.c b/security/keys/trusted-keys/trusted_pkwm.c
index bf42c6679245a..108db105b639f 100644
--- a/security/keys/trusted-keys/trusted_pkwm.c
+++ b/security/keys/trusted-keys/trusted_pkwm.c
@@ -3,6 +3,8 @@
* Copyright (C) 2025 IBM Corporation, Srish Srinivasan <ssrish@linux.ibm.com>
*/
+#define pr_fmt(fmt) "trusted_key: pwkm: " fmt
+
#include <keys/trusted_pkwm.h>
#include <keys/trusted-type.h>
#include <linux/build_bug.h>
--git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 6ea728f1eae6f..207be849796ed 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -6,6 +6,8 @@
* See Documentation/security/keys/trusted-encrypted.rst
*/
+#define pr_fmt(fmt) "trusted_key: tpm1: " fmt
+
#include <crypto/hash_info.h>
#include <crypto/sha1.h>
#include <crypto/utils.h>
--git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index 6340823f8b53c..2a540b1af0b33 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -4,6 +4,8 @@
* Copyright (C) 2014 Intel Corporation
*/
+#define pr_fmt(fmt) "trusted_key: tpm2: " fmt
+
#include <linux/asn1_encoder.h>
#include <linux/oid_registry.h>
#include <linux/string.h>
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-trusted-key-header-a544a4f149d2
Best regards,
--
Josh
^ permalink raw reply related
* Re: [PATCH v2 2/2] integrity: Add support for sigv3 verification using ML-DSA keys
From: Stefan Berger @ 2026-04-15 20:32 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <be3fdb81a322ab96e356e165b737c46f00c12cc3.camel@linux.ibm.com>
On 4/14/26 10:01 PM, Mimi Zohar wrote:
> On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
>> Add support for sigv3 signature verification using ML-DSA in pure mode.
>> When a sigv3 signature is verified, first check whether the key to use
>> for verification is an ML-DSA key and therefore uses a hashless signature
>> verification scheme. The hashless signature verification method uses the
>> ima_file_id structure directly for signature verification rather than
>> its digest.
>>
>> Suggested-by: Eric Biggers <ebiggers@kernel.org>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>>
>
> Thanks, Stefan.
>> ---
>> v2: Set hash_algo in public_key_signature to "none"
>> ---
>> security/integrity/digsig_asymmetric.c | 84 ++++++++++++++++++++++++--
>> 1 file changed, 79 insertions(+), 5 deletions(-)
>>
>> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
>> index e29ed73f15cd..c80cb2b117a6 100644
>> --- a/security/integrity/digsig_asymmetric.c
>> +++ b/security/integrity/digsig_asymmetric.c
>> @@ -190,17 +190,91 @@ static int calc_file_id_hash(enum evm_ima_xattr_type type,
>> return rc;
>> }
>>
>> +/*
>
> kernel-doc starts with "/**".
I followed the pattern of documentation of a static function that you
just moved:
/*
* calc_file_id_hash - calculate the hash of the ima_file_id struct data
* @type: xattr type [enum evm_ima_xattr_type]
>
>> + * asymmetric_verify_v3_hashless - Use hashless signature verification on sigv3
>> + * @key: The key to use for signature verification
>> + * @pk: The associated public key
>> + * @encoding: The encoding the key type uses
>> + * @sig: The signature
>> + * @siglen: The length of the xattr signature
>> + * @algo: The hash algorithm
>> + * @digest: The file digest
>> + *
>> + * Create an ima_file_id structure and use it for signature verification
>> + * directly. This can be used for ML-DSA in pure mode for example.
>
> Like the comments on 1/2, please add a comment here indicating that all callers
> must verify the signature length (siglen) and the public key (pk) is not NULL,
> before calling asymmetric_verify_v3_hashless(). Also indicate that the caller
> must free the key.
>
>> + */
>> +static int asymmetric_verify_v3_hashless(struct key *key,
>> + const struct public_key *pk,
>> + const char *encoding,
>> + const char *sig, int siglen,
>> + u8 algo,
>> + const u8 *digest)
>> +{
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + struct ima_file_id file_id = {
>> + .hash_type = hdr->type,
>> + .hash_algorithm = algo,
>> + };
>> + size_t digest_size = hash_digest_size[algo];
>
> Defer initializing the digest_size and .m_size, below, until after checking the
> hash algorithm is valid.
This function is called by asymmetric_verify. asymmetric_verify calls
calc_file_id_hash, which doesn't check algo for valid range, either. I
suppose it's an untrusted value at this point (IMA never checked it's
value for valid range?) an we should check it in asymmetric_verify then
to cover both cases? Or you want to check it individually?
>
>> + struct public_key_signature pks = {
>> + .m = (u8 *)&file_id,
>> + .m_size = sizeof(file_id) - (HASH_MAX_DIGESTSIZE - digest_size),
>> + .s = hdr->sig,
>> + .s_size = siglen - sizeof(*hdr),
>> + .pkey_algo = pk->pkey_algo,
>> + .hash_algo = "none",
>> + .encoding = encoding,
>> + };
>> + int ret;
>> +
>> + if (hdr->type != IMA_VERITY_DIGSIG &&
>> + hdr->type != EVM_IMA_XATTR_DIGSIG &&
>> + hdr->type != EVM_XATTR_PORTABLE_DIGSIG)
>> + return -EINVAL;
>> +
>> + if (pks.s_size != be16_to_cpu(hdr->sig_size))
>> + return -EBADMSG;
>> +
>> + memcpy(file_id.hash, digest, digest_size);
>
> First check the hash algorithm is valid, before using digest_size.
>
>> +
>> + ret = verify_signature(key, &pks);
>> + pr_debug("%s() = %d\n", __func__, ret);
>> + return ret;
>> +}
>> +
>> int asymmetric_verify_v3(struct key *keyring, const char *sig, int siglen,
>> const char *data, int datalen, u8 algo)
>> {
>> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> struct ima_max_digest_data hash;
>> + const struct public_key *pk;
>> + struct key *key;
>> int rc;
>>
>> - rc = calc_file_id_hash(hdr->type, algo, data, &hash);
>> - if (rc)
>> - return -EINVAL;
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>>
>> - return asymmetric_verify(keyring, sig, siglen, hash.digest,
>> - hash.hdr.length);
>> + pk = asymmetric_key_public_key(key);
>
> Please add a test to check that 'pk' isn't null.
>
>> + if (!strncmp(pk->pkey_algo, "mldsa", 5)) {
>> + rc = asymmetric_verify_v3_hashless(key, pk, "raw",
>> + sig, siglen, algo, data);
>> + } else {
>> + rc = calc_file_id_hash(hdr->type, algo, data, &hash);
>> + if (rc) {
>> + rc = -EINVAL;
>> + goto err_exit;
>> + }
>> +
>> + rc = asymmetric_verify_common(key, pk, sig, siglen, hash.digest,
>> + hash.hdr.length);
>> + }
>> +
>> +err_exit:
>
> Normally a label named 'err*' would be preceded by a return. Here, the label
> "err_exit" is always called, not only when there is an error. Please rename the
> label to something more appropriate - out, cleanup, etc.
Ok, will call it 'out'.
>
>> + key_put(key);
>> +
>> + return rc;
>> }
>
> thanks,
>
> Mimi
>
^ permalink raw reply
* Re: [PATCH v2 1/2] integrity: Refactor asymmetric_verify for reusability
From: Stefan Berger @ 2026-04-15 20:15 UTC (permalink / raw)
To: Mimi Zohar, linux-integrity, linux-security-module
Cc: linux-kernel, roberto.sassu, ebiggers
In-Reply-To: <0375ccecdfb77286dff7f40af5ddbd20f7d6e0fa.camel@linux.ibm.com>
On 4/14/26 10:00 PM, Mimi Zohar wrote:
> On Wed, 2026-04-08 at 13:41 -0400, Stefan Berger wrote:
>> Refactor asymmetric_verify for reusability. Have it call
>> asymmetric_verify_common with the signature verification key and the
>> public_key structure as parameters. sigv3 support for ML-DSA will need to
>> check the public key type first to decide how to do the signature
>> verification and therefore will have these parameters available for
>> calling asymmetric_verify_common.
>>
>> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
>
> Thanks, Stefan.
>
>> ---
>> security/integrity/digsig_asymmetric.c | 42 +++++++++++++++++---------
>> 1 file changed, 28 insertions(+), 14 deletions(-)
>>
>> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
>> index 6e68ec3becbd..e29ed73f15cd 100644
>> --- a/security/integrity/digsig_asymmetric.c
>> +++ b/security/integrity/digsig_asymmetric.c
>> @@ -79,18 +79,15 @@ static struct key *request_asymmetric_key(struct key *keyring, uint32_t keyid)
>> return key;
>> }
>>
>> -int asymmetric_verify(struct key *keyring, const char *sig,
>> - int siglen, const char *data, int datalen)
>> +static int asymmetric_verify_common(const struct key *key,
>> + const struct public_key *pk,
>> + const char *sig, int siglen,
>> + const char *data, int datalen)
>> {
>> - struct public_key_signature pks;
>> struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> - const struct public_key *pk;
>> - struct key *key;
>> + struct public_key_signature pks;
>> int ret;
>>
>> - if (siglen <= sizeof(*hdr))
>> - return -EBADMSG;
>> -
>> siglen -= sizeof(*hdr);
>
> Normally kernel-doc is unnecessary for static functions. Here, however, since
> only the caller verifies the signature length, there should be a kernel-doc
> function definition. It should indicate that all callers must verify the
> signature length (siglen) and that the public key (pk) is not NULL, before
> calling asymmetric_verify_common().
Will add.
>
>>
>> if (siglen != be16_to_cpu(hdr->sig_size))
>> @@ -99,15 +96,10 @@ int asymmetric_verify(struct key *keyring, const char *sig,
>> if (hdr->hash_algo >= HASH_ALGO__LAST)
>> return -ENOPKG;
>>
>> - key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> - if (IS_ERR(key))
>> - return PTR_ERR(key);
>> -
>> memset(&pks, 0, sizeof(pks));
>>
>> pks.hash_algo = hash_algo_name[hdr->hash_algo];
>>
>> - pk = asymmetric_key_public_key(key);
>> pks.pkey_algo = pk->pkey_algo;
>> if (!strcmp(pk->pkey_algo, "rsa")) {
>> pks.encoding = "pkcs1";
>> @@ -127,11 +119,33 @@ int asymmetric_verify(struct key *keyring, const char *sig,
>> pks.s_size = siglen;
>> ret = verify_signature(key, &pks);
>> out:
>> - key_put(key);
>
> The kernel-doc function definition should also indicate that the caller must
> free the key.
Ok, I will add it. However, symmetric_verify_common cannot free the key
since it is passed as const(!) struct key *key...
>
>> pr_debug("%s() = %d\n", __func__, ret);
>> return ret;
>> }
>>
>> +int asymmetric_verify(struct key *keyring, const char *sig,
>> + int siglen, const char *data, int datalen)
>> +{
>> + struct signature_v2_hdr *hdr = (struct signature_v2_hdr *)sig;
>> + const struct public_key *pk;
>> + struct key *key;
>> + int ret;
>> +
>> + if (siglen <= sizeof(*hdr))
>> + return -EBADMSG;
>> +
>> + key = request_asymmetric_key(keyring, be32_to_cpu(hdr->keyid));
>> + if (IS_ERR(key))
>> + return PTR_ERR(key);
>> + pk = asymmetric_key_public_key(key);
>
> Please add a test here making sure pk is not null.
As a separate patch for backporting?
Return -ENOKEY in case we hit a NULL pointer?
>
> thanks,
>
> Mimi
>
>> +
>> + ret = asymmetric_verify_common(key, pk, sig, siglen, data, datalen);
>> +
>> + key_put(key);
>> +
>> + return ret;
>> +}
>> +
>> /*
>> * calc_file_id_hash - calculate the hash of the ima_file_id struct data
>> * @type: xattr type [enum evm_ima_xattr_type]
>
^ permalink raw reply
* Re: [PATCH] ima: Use KEXEC_SIG_FORCE for rejecting unsigned kexec images
From: Mimi Zohar @ 2026-04-15 19:22 UTC (permalink / raw)
To: Chi Wang, roberto.sassu, dmitry.kasatkin, eric.snowberg
Cc: paul, jmorris, serge, linux-integrity, linux-security-module,
linux-kernel, Chi Wang
In-Reply-To: <20260415102319.431379-1-wangchi05@163.com>
On Wed, 2026-04-15 at 18:23 +0800, Chi Wang wrote:
> From: Chi Wang <wangchi@kylinos.cn>
>
> Following the split of KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE,
> only KEXEC_SIG_FORCE indicates that unsigned kernel images must be rejected.
> KEXEC_SIG alone enables signature verification but permits unsigned images,
> so it should not trigger the IMA appraisal denial for kexec_load.
>
> Update the condition in ima_load_data() to check for KEXEC_SIG_FORCE
> instead of KEXEC_SIG.
>
> Fixes: 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE")
>
> Signed-off-by: Chi Wang <wangchi@kylinos.cn>
It isn't enough to check whether CONFIG_KEXEC_SIG_FORCE is configured, since it
is possible to require the kexec kernel image to be signed at runtime. Based on
the IMA policy, IMA will call set_kexec_sig_enforced() to require the kexec
kernel image to be signed.
Mimi
> ---
> security/integrity/ima/ima_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 1d6229b156fb..ec70e78ab8cd 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -953,7 +953,7 @@ static int ima_load_data(enum kernel_load_data_id id, bool contents)
>
> switch (id) {
> case LOADING_KEXEC_IMAGE:
> - if (IS_ENABLED(CONFIG_KEXEC_SIG)
> + if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)
> && arch_ima_get_secureboot()) {
> pr_err("impossible to appraise a kernel image without a file descriptor; try using kexec_file_load syscall.\n");
> return -EACCES;
> --
> 2.25.1
^ permalink raw reply
* [PATCH v3 2/2] tpm: tpm_tis: stop transmit if retries are exhausted
From: Jacqueline Wong @ 2026-04-15 16:00 UTC (permalink / raw)
To: linux-integrity
Cc: jarkko, peterhuewe, jgg, axelrasmussen, jhand, Jacqueline Wong
In-Reply-To: <20260415160006.2275325-1-jacqwong@google.com>
tpm_tis_send_main() will attempt to retry sending data TPM_RETRY times.
Currently, if those retries are exhausted, the driver will attempt to
call execute. The TPM will be in the wrong state, leading to the
operation simply timing out.
Instead, if there is still an error after retries are exhausted, return
that error immediately.
Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors")
Signed-off-by: Jacqueline Wong <jacqwong@google.com>
Signed-off-by: Jordan Hand <jhand@google.com>
---
drivers/char/tpm/tpm_tis_core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index acb91bf1e5f5..21d79ad3b164 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -556,11 +556,16 @@ static int tpm_tis_send_main(struct tpm_chip *chip, const u8 *buf, size_t len)
break;
else if (rc != -EAGAIN && rc != -EIO)
/* Data transfer failed, not recoverable */
- return rc;
+ goto out_err;
usleep_range(priv->timeout_min, priv->timeout_max);
}
+ if (rc == -EAGAIN || rc == -EIO) {
+ dev_err(&chip->dev, "Exhausted %d tpm_tis_send_data retries\n", TPM_RETRY);
+ goto out_err;
+ }
+
/* go and do it */
rc = tpm_tis_write8(priv, TPM_STS(priv->locality), TPM_STS_GO);
if (rc < 0)
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH v3 1/2] tpm: tpm_tis: add error logging for data transfer
From: Jacqueline Wong @ 2026-04-15 16:00 UTC (permalink / raw)
To: linux-integrity
Cc: jarkko, peterhuewe, jgg, axelrasmussen, jhand, Jacqueline Wong
In-Reply-To: <20260415160006.2275325-1-jacqwong@google.com>
Add logging to more easily determine reason for transmit failure
Fixes: 280db21e153d8 ("tpm_tis: Resend command to recover from data transfer errors")
Signed-off-by: Jacqueline Wong <jacqwong@google.com>
Signed-off-by: Jordan Hand <jhand@google.com>
---
drivers/char/tpm/tpm_tis_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index e2a1769081b1..acb91bf1e5f5 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -471,6 +471,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len)
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
rc = -EIO;
+ dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be set. sts = 0x%08x\n",
+ status);
goto out_err;
}
}
@@ -491,6 +493,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, const u8 *buf, size_t len)
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) {
rc = -EIO;
+ dev_err(&chip->dev, "TPM_STS_DATA_EXPECT should be unset. sts = 0x%08x\n",
+ status);
goto out_err;
}
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply related
* [PATCH v3 0/2] tpm_tis: fix retry exhaustion and add logging
From: Jacqueline Wong @ 2026-04-15 16:00 UTC (permalink / raw)
To: linux-integrity
Cc: jarkko, peterhuewe, jgg, axelrasmussen, jhand, Jacqueline Wong
The Fix:
- Patch 1: Adds error logs to identify the specific hardware status mismatch.
- Patch 2: Stops execution immediately when retries are exhausted.
v3 changes:
- Improved code alignment to pass checkpatch --strict.
v2 changes:
- Split logging and logic into separate patches.
- Added retry count to the error message.
- Included dmesg traces below.
Testing:
Dmesg traces obtained using error injection to simulate status register mismatches.
Before:
[ 130.288751] tpm tpm0: Operation Timed out
[ 250.306070] tpm tpm0: Operation Timed out
[ 250.310173] tpm tpm0: A TPM error (-62) occurred attempting to determine the timeouts
After:
[ 10.271547] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
...
[ 10.646283] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
[ 10.653461] tpm tpm0: Exhausted 50 tpm_tis_send_data retries
[ 10.659304] tpm tpm0: tpm_try_transmit: send(): error -5
[ 10.665435] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
...
[ 11.037198] tpm tpm0: TPM_STS_DATA_EXPECT should be unset. sts = 0x00000080
[ 11.044441] tpm tpm0: Exhausted 50 tpm_tis_send_data retries
[ 11.050288] tpm tpm0: tpm_try_transmit: send(): error -5
[ 11.055723] tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
Jacqueline Wong (2):
tpm: tpm_tis: add error logging for data transfer
tpm: tpm_tis: stop transmit if retries are exhausted
drivers/char/tpm/tpm_tis_core.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
2.54.0.rc0.605.g598a273b03-goog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox