* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Yeoreum Yun @ 2026-04-18 10:34 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <87se8sbozv.wl-maz@kernel.org>
Hi Marc,
> On Fri, 17 Apr 2026 18:57:59 +0100,
> Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> >
> > When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> > Otherwise, pKVM cannot negotiate the FF-A version or
> > obtain RX/TX buffer information, leading to failures in FF-A calls.
> >
> > During FF-A driver initialization, check whether pKVM has been initialized.
> > If not, defer probing of the FF-A driver.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > ---
> > arch/arm64/kvm/arm.c | 1 +
> > drivers/firmware/arm_ffa/driver.c | 12 ++++++++++++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 410ffd41fd73..0f517b1c05cd 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -119,6 +119,7 @@ bool is_kvm_arm_initialised(void)
> > {
> > return kvm_arm_initialised;
> > }
> > +EXPORT_SYMBOL(is_kvm_arm_initialised);
>
> EXPORT_SYMBOL_GPL(), please.
Okay.
>
> >
> > int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> > {
> > diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> > index 02c76ac1570b..2647d6554afd 100644
> > --- a/drivers/firmware/arm_ffa/driver.c
> > +++ b/drivers/firmware/arm_ffa/driver.c
> > @@ -42,6 +42,8 @@
> > #include <linux/uuid.h>
> > #include <linux/xarray.h>
> >
> > +#include <asm/virt.h>
> > +
> > #include "common.h"
> >
> > #define FFA_DRIVER_VERSION FFA_VERSION_1_2
> > @@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
> > u32 buf_sz;
> > size_t rxtx_bufsz = SZ_4K;
> >
> > + /*
> > + * When pKVM is enabled, the FF-A driver must be initialized
> > + * after pKVM initialization. Otherwise, pKVM cannot negotiate
> > + * the FF-A version or obtain RX/TX buffer information,
> > + * which leads to failures in FF-A calls.
> > + */
> > + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
> > + !is_kvm_arm_initialised())
> > + return -EPROBE_DEFER;
> > +
>
> That's still fundamentally wrong: pkvm is not ready until
> finalize_pkvm() has finished, and that's not indicated by
> is_kvm_arm_initialised().
Thanks. I miss the TSC bit set in here.
IMHO, I'd like to make an new state check function --
is_pkvm_arm_initialised() so that ff-a driver to know whether
pkvm is initialised.
or any other suggestion?
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
From: Marc Zyngier @ 2026-04-18 9:24 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, peterhuewe, jarkko,
jgg, sudeep.holla, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <20260417175759.3191279-5-yeoreum.yun@arm.com>
On Fri, 17 Apr 2026 18:57:59 +0100,
Yeoreum Yun <yeoreum.yun@arm.com> wrote:
>
> When pKVM is enabled, the FF-A driver must be initialized after pKVM.
> Otherwise, pKVM cannot negotiate the FF-A version or
> obtain RX/TX buffer information, leading to failures in FF-A calls.
>
> During FF-A driver initialization, check whether pKVM has been initialized.
> If not, defer probing of the FF-A driver.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> arch/arm64/kvm/arm.c | 1 +
> drivers/firmware/arm_ffa/driver.c | 12 ++++++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 410ffd41fd73..0f517b1c05cd 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -119,6 +119,7 @@ bool is_kvm_arm_initialised(void)
> {
> return kvm_arm_initialised;
> }
> +EXPORT_SYMBOL(is_kvm_arm_initialised);
EXPORT_SYMBOL_GPL(), please.
>
> int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> {
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index 02c76ac1570b..2647d6554afd 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -42,6 +42,8 @@
> #include <linux/uuid.h>
> #include <linux/xarray.h>
>
> +#include <asm/virt.h>
> +
> #include "common.h"
>
> #define FFA_DRIVER_VERSION FFA_VERSION_1_2
> @@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
> u32 buf_sz;
> size_t rxtx_bufsz = SZ_4K;
>
> + /*
> + * When pKVM is enabled, the FF-A driver must be initialized
> + * after pKVM initialization. Otherwise, pKVM cannot negotiate
> + * the FF-A version or obtain RX/TX buffer information,
> + * which leads to failures in FF-A calls.
> + */
> + if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
> + !is_kvm_arm_initialised())
> + return -EPROBE_DEFER;
> +
That's still fundamentally wrong: pkvm is not ready until
finalize_pkvm() has finished, and that's not indicated by
is_kvm_arm_initialised().
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [GIT PULL] integrity: subsystem fixes for v7.1
From: pr-tracker-bot @ 2026-04-17 22:58 UTC (permalink / raw)
To: Mimi Zohar; +Cc: Linus Torvalds, linux-integrity, linux-kernel, Roberto Sassu
In-Reply-To: <67d7f2aba75660bf44478e5718820061390b080e.camel@linux.ibm.com>
The pull request you sent on Thu, 16 Apr 2026 09:18:49 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/ tags/integrity-v7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9cdca336677b4d15579ec462e33c8a330ab3a9de
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v5 2/3] ima: trim N IMA event log records
From: steven chen @ 2026-04-17 21:26 UTC (permalink / raw)
To: Roberto Sassu, linux-integrity
Cc: zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, corbet,
serge, paul, jmorris, linux-security-module, anirudhve,
gregorylumen, nramas, sushring, linux-doc, steven chen
In-Reply-To: <b0b65c5a2d407301905dc4232eee4b16030920c8.camel@huaweicloud.com>
On 4/7/2026 9:19 AM, Roberto Sassu wrote:
> On Wed, 2026-04-01 at 10:29 -0700, steven chen wrote:
>> Trim N entries of the IMA event logs. Do not clean the hash table.
> The very first change of this patch is the kernel option
> ima_flush_htable option that I introduced for my use case.
>
> At the bottom of this patch you actually check the ima_flush_htable
> boolean, and delete the measurements entries without disconnecting them
> from the hash table, so the digest lookup is done on freed memory.
>
> Next, you duplicated my changes regarding the measurements list
> counter. But instead of removing the old counter from the hash table,
> you keep incrementing both, but use the new one.
>
> In ima_log_trim_open(), you use again my duplicated code to manage
> exclusive write/concurrent read scheme for the measurement interfaces.
> However, for read, if the process does not have CAP_SYS_ADMIN it falls
> back calling _ima_measurements_open(). Not sure it was intended.
Hi Roberto,
I acknowledged these are coming from you in my cover letter. Please
let me know the best way to show your contribution and I will update
in my next version.
All above issues you mentioned, I will update in next version.
> And, in ima_log_trim_release(), you check again CAP_SYS_ADMIN which is
> redundant, you would not reach this code if the same requirements were
> not met at open time. You also return an error on close().
Will update in next version.
Thanks,
> In ima_log_trim_write(), you do manual string to number conversion for
> your first number and use kstrtoul() for the second.
>
> The measurements lists and the associated counter are atomically
> updated in ima_add_digest_entry(), but not atomically accessed in
> ima_delete_event_log(). Also, the measurements list is traversed
> without _rcu variant or lock.
Will update in next version.
Thanks
>
> While this trimming scheme aims at minimizing the kernel space and user
> space delay, it also introduces the following problem. If two agents
> perform a TPM quote that include a different number of entries, there
> is no guarantee that the one willing to trim less entries wins. Which
> means that, one agent could end up not seeing the most recent entries,
> as they were already trimmed by the other agent.
This should be acceptable: the second trim request will be rejected and
the agent can find all logs in user space if all user agents handle the log
in the right way.
Also there is other way to do it: the user agent can hold the list by open
the ima_trim_log with write permission during reading, attestation, trim
period.
In this way, the user agent for "Trim N method" will have similar user
space hold time
as "staged method" but has less kernel list lock time, and user agent
requirement
for "Trim N method" is much simple than that for "stage method".
>
> My solution is not affected by this problem, since there will be only
> one process collecting all the measurements in user space and exposing
> them to the agents.
Please see above response.
Thanks,
Steven
>
> Also, I didn't understand why T and ima_measure_users have to be
> preserved on soft reboots. Especially ima_measure_users reflects the
> state of open files for a particular kernel, but on soft reboot a new
> kernel is booted.
>
> I personally will not endorse a solution based on the ima_trim_log
> interface. I could accept trimming N even more efficiently than we
> currently do with a lockless walk to determine the cutting position in
> ima_queue_stage(), so that we don't need to splice back entries to the
> measurement list. This would be a replacement of patch 11 in my patch
> set, but this would be as far as I would like to go.
>
> Roberto
>
>> The values saved in hash table were already used.
>>
>> Provide a userspace interface ima_trim_log:
>> When read this interface, it returns total number T of entries trimmed
>> since system boot up.
>> When write to this interface need to provide two numbers T:N to let
>> kernel to trim N entries of IMA event logs.
>>
>> Kernel measurement list lock time performance improvement by not
>> clean the hash table.
>>
>> when kernel get log trim request T:N
>> - Get the T, compare with the total trimmed number
>> - if equal, then do trim N and change T to T+N
>> - else return error
>>
>> Signed-off-by: steven chen <chenste@linux.microsoft.com>
>> ---
>> .../admin-guide/kernel-parameters.txt | 4 +
>> security/integrity/ima/ima.h | 4 +-
>> security/integrity/ima/ima_fs.c | 198 +++++++++++++++++-
>> security/integrity/ima/ima_kexec.c | 2 +-
>> security/integrity/ima/ima_queue.c | 96 +++++++++
>> 5 files changed, 296 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index e92c0056e4e0..cd1a1d0bf0e2 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2197,6 +2197,10 @@
>> Use the canonical format for the binary runtime
>> measurements, instead of host native format.
>>
>> + ima_flush_htable [IMA]
>> + Flush the measurement list hash table when trim all
>> + or a part of it for deletion.
>> +
>> ima_hash= [IMA]
>> Format: { md5 | sha1 | rmd160 | sha256 | sha384
>> | sha512 | ... }
>> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
>> index e3d71d8d56e3..5cbee3a295a0 100644
>> --- a/security/integrity/ima/ima.h
>> +++ b/security/integrity/ima/ima.h
>> @@ -243,11 +243,13 @@ void ima_post_key_create_or_update(struct key *keyring, struct key *key,
>> const void *payload, size_t plen,
>> unsigned long flags, bool create);
>> #endif
>> -
>> +extern atomic_long_t ima_number_entries;
>> #ifdef CONFIG_IMA_KEXEC
>> void ima_measure_kexec_event(const char *event_name);
>> +long ima_delete_event_log(long req_val);
>> #else
>> static inline void ima_measure_kexec_event(const char *event_name) {}
>> +static inline long ima_delete_event_log(long req_val) { return 0; }
>> #endif
>>
>> /*
>> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
>> index 87045b09f120..8e26e0f34311 100644
>> --- a/security/integrity/ima/ima_fs.c
>> +++ b/security/integrity/ima/ima_fs.c
>> @@ -21,6 +21,9 @@
>> #include <linux/rcupdate.h>
>> #include <linux/parser.h>
>> #include <linux/vmalloc.h>
>> +#include <linux/ktime.h>
>> +#include <linux/timekeeping.h>
>> +#include <linux/ima.h>
>>
>> #include "ima.h"
>>
>> @@ -38,6 +41,17 @@ __setup("ima_canonical_fmt", default_canonical_fmt_setup);
>>
>> static int valid_policy = 1;
>>
>> +#define IMA_LOG_TRIM_REQ_NUM_LENGTH 15
>> +#define IMA_LOG_TRIM_REQ_TOTAL_LENGTH 32
>> +atomic_long_t ima_number_entries = ATOMIC_LONG_INIT(0);
>> +static long trimcount;
>> +/* mutex protects atomicity of trimming measurement list
>> + * and also protects atomicity the measurement list read
>> + * write operation.
>> + */
>> +static DEFINE_MUTEX(ima_measure_lock);
>> +static long ima_measure_users;
>> +
>> static ssize_t ima_show_htable_value(char __user *buf, size_t count,
>> loff_t *ppos, atomic_long_t *val)
>> {
>> @@ -64,8 +78,7 @@ static ssize_t ima_show_measurements_count(struct file *filp,
>> char __user *buf,
>> size_t count, loff_t *ppos)
>> {
>> - return ima_show_htable_value(buf, count, ppos, &ima_htable.len);
>> -
>> + return ima_show_htable_value(buf, count, ppos, &ima_number_entries);
>> }
>>
>> static const struct file_operations ima_measurements_count_ops = {
>> @@ -202,16 +215,77 @@ static const struct seq_operations ima_measurments_seqops = {
>> .show = ima_measurements_show
>> };
>>
>> +/*
>> + * _ima_measurements_open - open the IMA measurements file
>> + * @inode: inode of the file being opened
>> + * @file: file being opened
>> + * @seq_ops: sequence operations for the file
>> + *
>> + * Returns 0 on success, or negative error code.
>> + * Implements mutual exclusion between readers and writer
>> + * of the measurements file. Multiple readers are allowed,
>> + * but writer get exclusive access only no other readers/writers.
>> + * Readers is not allowed when there is a writer.
>> + */
>> +static int _ima_measurements_open(struct inode *inode, struct file *file,
>> + const struct seq_operations *seq_ops)
>> +{
>> + bool write = !!(file->f_mode & FMODE_WRITE);
>> + int ret;
>> +
>> + if (write && !capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + mutex_lock(&ima_measure_lock);
>> + if ((write && ima_measure_users != 0) ||
>> + (!write && ima_measure_users < 0)) {
>> + mutex_unlock(&ima_measure_lock);
>> + return -EBUSY;
>> + }
>> +
>> + ret = seq_open(file, seq_ops);
>> + if (ret < 0) {
>> + mutex_unlock(&ima_measure_lock);
>> + return ret;
>> + }
>> +
>> + if (write)
>> + ima_measure_users--;
>> + else
>> + ima_measure_users++;
>> +
>> + mutex_unlock(&ima_measure_lock);
>> + return ret;
>> +}
>> +
>> static int ima_measurements_open(struct inode *inode, struct file *file)
>> {
>> - return seq_open(file, &ima_measurments_seqops);
>> + return _ima_measurements_open(inode, file, &ima_measurments_seqops);
>> +}
>> +
>> +static int ima_measurements_release(struct inode *inode, struct file *file)
>> +{
>> + bool write = !!(file->f_mode & FMODE_WRITE);
>> + int ret;
>> +
>> + mutex_lock(&ima_measure_lock);
>> + ret = seq_release(inode, file);
>> + if (!ret) {
>> + if (!write)
>> + ima_measure_users--;
>> + else
>> + ima_measure_users++;
>> + }
>> +
>> + mutex_unlock(&ima_measure_lock);
>> + return ret;
>> }
>>
>> static const struct file_operations ima_measurements_ops = {
>> .open = ima_measurements_open,
>> .read = seq_read,
>> .llseek = seq_lseek,
>> - .release = seq_release,
>> + .release = ima_measurements_release,
>> };
>>
>> void ima_print_digest(struct seq_file *m, u8 *digest, u32 size)
>> @@ -279,14 +353,114 @@ static const struct seq_operations ima_ascii_measurements_seqops = {
>>
>> static int ima_ascii_measurements_open(struct inode *inode, struct file *file)
>> {
>> - return seq_open(file, &ima_ascii_measurements_seqops);
>> + return _ima_measurements_open(inode, file, &ima_ascii_measurements_seqops);
>> }
>>
>> static const struct file_operations ima_ascii_measurements_ops = {
>> .open = ima_ascii_measurements_open,
>> .read = seq_read,
>> .llseek = seq_lseek,
>> - .release = seq_release,
>> + .release = ima_measurements_release,
>> +};
>> +
>> +static int ima_log_trim_open(struct inode *inode, struct file *file)
>> +{
>> + bool write = !!(file->f_mode & FMODE_WRITE);
>> +
>> + if (!write && capable(CAP_SYS_ADMIN))
>> + return 0;
>> + else if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + return _ima_measurements_open(inode, file, &ima_measurments_seqops);
>> +}
>> +
>> +static ssize_t ima_log_trim_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
>> +{
>> + char tmpbuf[IMA_LOG_TRIM_REQ_NUM_LENGTH];
>> + ssize_t len;
>> +
>> + len = scnprintf(tmpbuf, sizeof(tmpbuf), "%li\n", trimcount);
>> + return simple_read_from_buffer(buf, size, ppos, tmpbuf, len);
>> +}
>> +
>> +static ssize_t ima_log_trim_write(struct file *file,
>> + const char __user *buf, size_t datalen, loff_t *ppos)
>> +{
>> + char tmpbuf[IMA_LOG_TRIM_REQ_TOTAL_LENGTH];
>> + char *p = tmpbuf;
>> + long count, ret, val = 0, max = LONG_MAX;
>> +
>> + if (*ppos > 0 || datalen > IMA_LOG_TRIM_REQ_TOTAL_LENGTH || datalen < 2) {
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + if (copy_from_user(tmpbuf, buf, datalen) != 0) {
>> + ret = -EFAULT;
>> + goto out;
>> + }
>> +
>> + p = tmpbuf;
>> +
>> + while (*p && *p != ':') {
>> + if (!isdigit((unsigned char)*p))
>> + return -EINVAL;
>> +
>> + /* digit value */
>> + int d = *p - '0';
>> +
>> + /* overflow check: val * 10 + d > max -> (val > (max - d) / 10) */
>> + if (val > (max - d) / 10)
>> + return -ERANGE;
>> +
>> + val = val * 10 + d;
>> + p++;
>> + }
>> +
>> + if (*p != ':')
>> + return -EINVAL;
>> +
>> + /* verify trim count matches */
>> + if (val != trimcount)
>> + return -EINVAL;
>> +
>> + p++; /* skip ':' */
>> + ret = kstrtoul(p, 0, &count);
>> +
>> + if (ret < 0)
>> + goto out;
>> +
>> + ret = ima_delete_event_log(count);
>> +
>> + if (ret < 0)
>> + goto out;
>> +
>> + trimcount += ret;
>> +
>> + ret = datalen;
>> +out:
>> + return ret;
>> +}
>> +
>> +static int ima_log_trim_release(struct inode *inode, struct file *file)
>> +{
>> + bool write = !!(file->f_mode & FMODE_WRITE);
>> +
>> + if (!write && capable(CAP_SYS_ADMIN))
>> + return 0;
>> + else if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + return ima_measurements_release(inode, file);
>> +}
>> +
>> +static const struct file_operations ima_log_trim_ops = {
>> + .open = ima_log_trim_open,
>> + .read = ima_log_trim_read,
>> + .write = ima_log_trim_write,
>> + .llseek = generic_file_llseek,
>> + .release = ima_log_trim_release
>> };
>>
>> static ssize_t ima_read_policy(char *path)
>> @@ -528,6 +702,18 @@ int __init ima_fs_init(void)
>> goto out;
>> }
>>
>> + if (IS_ENABLED(CONFIG_IMA_LOG_TRIMMING)) {
>> + dentry = securityfs_create_file("ima_trim_log",
>> + S_IRUSR | S_IRGRP | S_IWUSR | S_IWGRP,
>> + ima_dir, NULL, &ima_log_trim_ops);
>> + if (IS_ERR(dentry)) {
>> + ret = PTR_ERR(dentry);
>> + goto out;
>> + }
>> + }
>> +
>> + trimcount = 0;
>> +
>> dentry = securityfs_create_file("runtime_measurements_count",
>> S_IRUSR | S_IRGRP, ima_dir, NULL,
>> &ima_measurements_count_ops);
>> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
>> index 7362f68f2d8b..bee997683e03 100644
>> --- a/security/integrity/ima/ima_kexec.c
>> +++ b/security/integrity/ima/ima_kexec.c
>> @@ -41,7 +41,7 @@ void ima_measure_kexec_event(const char *event_name)
>> int n;
>>
>> buf_size = ima_get_binary_runtime_size();
>> - len = atomic_long_read(&ima_htable.len);
>> + len = atomic_long_read(&ima_number_entries);
>>
>> n = scnprintf(ima_kexec_event, IMA_KEXEC_EVENT_LEN,
>> "kexec_segment_size=%lu;ima_binary_runtime_size=%lu;"
>> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
>> index 590637e81ad1..07225e19b9b5 100644
>> --- a/security/integrity/ima/ima_queue.c
>> +++ b/security/integrity/ima/ima_queue.c
>> @@ -22,6 +22,14 @@
>>
>> #define AUDIT_CAUSE_LEN_MAX 32
>>
>> +bool ima_flush_htable;
>> +static int __init ima_flush_htable_setup(char *str)
>> +{
>> + ima_flush_htable = true;
>> + return 1;
>> +}
>> +__setup("ima_flush_htable", ima_flush_htable_setup);
>> +
>> /* pre-allocated array of tpm_digest structures to extend a PCR */
>> static struct tpm_digest *digests;
>>
>> @@ -114,6 +122,7 @@ static int ima_add_digest_entry(struct ima_template_entry *entry,
>> list_add_tail_rcu(&qe->later, &ima_measurements);
>>
>> atomic_long_inc(&ima_htable.len);
>> + atomic_long_inc(&ima_number_entries);
>> if (update_htable) {
>> key = ima_hash_key(entry->digests[ima_hash_algo_idx].digest);
>> hlist_add_head_rcu(&qe->hnext, &ima_htable.queue[key]);
>> @@ -220,6 +229,93 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
>> return result;
>> }
>>
>> +/**
>> + * ima_delete_event_log - delete IMA event entry
>> + * @num_records: number of records to delete
>> + *
>> + * delete num_records entries off the measurement list.
>> + * Returns num_records, or negative error code.
>> + */
>> +long ima_delete_event_log(long num_records)
>> +{
>> + long len, cur = num_records, tmp_len = 0;
>> + struct ima_queue_entry *qe, *qe_tmp;
>> + LIST_HEAD(ima_measurements_to_delete);
>> + struct list_head *list_ptr;
>> +
>> + if (!IS_ENABLED(CONFIG_IMA_LOG_TRIMMING))
>> + return -EOPNOTSUPP;
>> +
>> + if (num_records <= 0)
>> + return num_records;
>> +
>> + list_ptr = &ima_measurements;
>> +
>> + len = atomic_long_read(&ima_number_entries);
>> +
>> + if (num_records <= len) {
>> + list_for_each_entry(qe, list_ptr, later) {
>> + if (cur > 0) {
>> + tmp_len += get_binary_runtime_size(qe->entry);
>> + --cur;
>> + }
>> + if (cur == 0) {
>> + qe_tmp = qe;
>> + break;
>> + }
>> + }
>> + }
>> + else {
>> + return -ENOENT;
>> + }
>> +
>> +
>> + mutex_lock(&ima_extend_list_mutex);
>> + len = atomic_long_read(&ima_number_entries);
>> +
>> + if (num_records == len) {
>> + list_replace(&ima_measurements, &ima_measurements_to_delete);
>> + INIT_LIST_HEAD(&ima_measurements);
>> + atomic_long_set(&ima_number_entries, 0);
>> + list_ptr = &ima_measurements_to_delete;
>> + }
>> + else {
>> + __list_cut_position(&ima_measurements_to_delete, &ima_measurements,
>> + &qe_tmp->later);
>> + atomic_long_sub(num_records, &ima_number_entries);
>> + if (IS_ENABLED(CONFIG_IMA_KEXEC))
>> + binary_runtime_size -= tmp_len;
>> + }
>> +
>> + mutex_unlock(&ima_extend_list_mutex);
>> +
>> + if (ima_flush_htable)
>> + synchronize_rcu();
>> +
>> + list_for_each_entry_safe(qe, qe_tmp, &ima_measurements_to_delete, later) {
>> + /*
>> + * Ok because after list delete qe is only accessed by
>> + * ima_lookup_digest_entry().
>> + */
>> + for (int i = 0; i < qe->entry->template_desc->num_fields; i++) {
>> + kfree(qe->entry->template_data[i].data);
>> + qe->entry->template_data[i].data = NULL;
>> + qe->entry->template_data[i].len = 0;
>> + }
>> +
>> + list_del(&qe->later);
>> +
>> + /* No leak if !ima_flush_htable, referenced by ima_htable. */
>> + if (ima_flush_htable) {
>> + kfree(qe->entry->digests);
>> + kfree(qe->entry);
>> + kfree(qe);
>> + }
>> + }
>> +
>> + return num_records;
>> +}
>> +
>> int ima_restore_measurement_entry(struct ima_template_entry *entry)
>> {
>> int result = 0;
^ permalink raw reply
* [syzbot] [integrity?] [lsm?] BUG: sleeping function called from invalid context in page_cache_ra_unbounded
From: syzbot @ 2026-04-17 18:11 UTC (permalink / raw)
To: dmitry.kasatkin, eric.snowberg, jmorris, linux-integrity,
linux-kernel, linux-security-module, paul, roberto.sassu, serge,
syzkaller-bugs, zohar
Hello,
syzbot found the following issue on:
HEAD commit: 1c7cc4904160 Add linux-next specific files for 20260413
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=104e10ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=56c2b36de3316f1b
dashboard link: https://syzkaller.appspot.com/bug?extid=77103043d0c16dbc71ae
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/91a765b703da/disk-1c7cc490.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/da75a3061146/vmlinux-1c7cc490.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d55367ced048/bzImage-1c7cc490.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+77103043d0c16dbc71ae@syzkaller.appspotmail.com
cgroup: Unknown subsys name 'rlimit'
BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:323
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5809, name: syz-executor
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
3 locks held by syz-executor/5809:
#0: ffff888025b9e458 (&ima_iint_mutex_key[depth]){+.+.}-{4:4}, at: process_measurement+0x7fd/0x1c90 security/integrity/ima/ima_main.c:319
#1: ffff8880406185f0 (mapping.invalidate_lock#2){++++}-{4:4}, at: filemap_invalidate_lock_shared include/linux/fs.h:1094 [inline]
#1: ffff8880406185f0 (mapping.invalidate_lock#2){++++}-{4:4}, at: do_page_cache_ra mm/readahead.c:333 [inline]
#1: ffff8880406185f0 (mapping.invalidate_lock#2){++++}-{4:4}, at: page_cache_ra_order+0x2a5/0x490 mm/readahead.c:538
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
CPU: 0 UID: 0 PID: 5809 Comm: syz-executor Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
__might_resched+0x329/0x480 kernel/sched/core.c:9162
might_alloc include/linux/sched/mm.h:323 [inline]
prepare_alloc_pages+0x1f0/0x6b0 mm/page_alloc.c:4995
__alloc_frozen_pages_noprof+0x12f/0x380 mm/page_alloc.c:5215
alloc_pages_mpol+0xd1/0x380 mm/mempolicy.c:2490
alloc_frozen_pages_noprof mm/mempolicy.c:2561 [inline]
alloc_pages_noprof+0xd2/0x2f0 mm/mempolicy.c:2581
folio_alloc_noprof+0x22/0xc0 mm/mempolicy.c:2591
filemap_alloc_folio_noprof+0x111/0x4d0 mm/filemap.c:1013
ractl_alloc_folio mm/readahead.c:189 [inline]
page_cache_ra_unbounded+0x2f7/0x980 mm/readahead.c:277
do_page_cache_ra mm/readahead.c:334 [inline]
page_cache_ra_order+0x2b5/0x490 mm/readahead.c:538
filemap_readahead mm/filemap.c:2663 [inline]
filemap_get_pages+0x832/0x1e70 mm/filemap.c:2709
filemap_read+0x44a/0x1240 mm/filemap.c:2805
__kernel_read+0x50d/0x9c0 fs/read_write.c:532
integrity_kernel_read+0x89/0xd0 security/integrity/iint.c:28
ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:222 [inline]
ima_calc_file_hash+0x452/0x870 security/integrity/ima/ima_crypto.c:280
ima_collect_measurement+0x523/0x9d0 security/integrity/ima/ima_api.c:300
process_measurement+0x12d9/0x1c90 security/integrity/ima/ima_main.c:425
ima_file_check+0xe1/0x130 security/integrity/ima/ima_main.c:685
security_file_post_open+0xb3/0x260 security/security.c:2755
do_open fs/namei.c:4701 [inline]
path_openat+0x2e88/0x38a0 fs/namei.c:4858
do_file_open+0x23e/0x4a0 fs/namei.c:4887
file_open_name+0x162/0x1c0 fs/open.c:1322
__do_sys_swapon mm/swapfile.c:3574 [inline]
__se_sys_swapon+0x856/0x2010 mm/swapfile.c:3539
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4a4d9cc7d7
Code: 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a7 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc336ba3b8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a7
RAX: ffff[ 83.300808][ T5809] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007f4a4d9cc7d7
RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00007f4a4da62e5b
RBP: 00007f4a4da62e5b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000008 R11: 0000000000000246 R12: 00007f4a4dc163e0
R13: 00007f4a4da7dd26 R14: 0000000000200000 R15: 00007f4a4dc163a0
</TASK>
=============================
[ BUG: Invalid wait context ]
syzkaller #0 Tainted: G W
-----------------------------
syz-executor/5809 is trying to lock:
ffff8880406185f0 (mapping.invalidate_lock#2){++++}-{4:4}, at: filemap_invalidate_lock_shared include/linux/fs.h:1094 [inline]
ffff8880406185f0 (mapping.invalidate_lock#2){++++}-{4:4}, at: do_page_cache_ra mm/readahead.c:333 [inline]
ffff8880406185f0 (mapping.invalidate_lock#2){++++}-{4:4}, at: page_cache_ra_order+0x2a5/0x490 mm/readahead.c:538
other info that might help us debug this:
context-{5:5}
2 locks held by syz-executor/5809:
#0: ffff888025b9e458 (&ima_iint_mutex_key[depth]){+.+.}-{4:4}, at: process_measurement+0x7fd/0x1c90 security/integrity/ima/ima_main.c:319
#1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
#1: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
stack backtrace:
CPU: 0 UID: 0 PID: 5809 Comm: syz-executor Tainted: G W syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_lock_invalid_wait_context kernel/locking/lockdep.c:4832 [inline]
check_wait_context kernel/locking/lockdep.c:4904 [inline]
__lock_acquire+0xec1/0x2cf0 kernel/locking/lockdep.c:5189
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5870
down_read+0x97/0x200 kernel/locking/rwsem.c:1568
filemap_invalidate_lock_shared include/linux/fs.h:1094 [inline]
do_page_cache_ra mm/readahead.c:333 [inline]
page_cache_ra_order+0x2a5/0x490 mm/readahead.c:538
filemap_readahead mm/filemap.c:2663 [inline]
filemap_get_pages+0x832/0x1e70 mm/filemap.c:2709
filemap_read+0x44a/0x1240 mm/filemap.c:2805
__kernel_read+0x50d/0x9c0 fs/read_write.c:532
integrity_kernel_read+0x89/0xd0 security/integrity/iint.c:28
ima_calc_file_hash_tfm security/integrity/ima/ima_crypto.c:222 [inline]
ima_calc_file_hash+0x452/0x870 security/integrity/ima/ima_crypto.c:280
ima_collect_measurement+0x523/0x9d0 security/integrity/ima/ima_api.c:300
process_measurement+0x12d9/0x1c90 security/integrity/ima/ima_main.c:425
ima_file_check+0xe1/0x130 security/integrity/ima/ima_main.c:685
security_file_post_open+0xb3/0x260 security/security.c:2755
do_open fs/namei.c:4701 [inline]
path_openat+0x2e88/0x38a0 fs/namei.c:4858
do_file_open+0x23e/0x4a0 fs/namei.c:4887
file_open_name+0x162/0x1c0 fs/open.c:1322
__do_sys_swapon mm/swapfile.c:3574 [inline]
__se_sys_swapon+0x856/0x2010 mm/swapfile.c:3539
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4a4d9cc7d7
Code: 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a7 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc336ba3b8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a7
RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007f4a4d9cc7d7
RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00007f4a4da62e5b
RBP: 00007f4a4da62e5b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000008 R11: 0000000000000246 R12: 00007f4a4dc163e0
R13: 00007f4a4da7dd26 R14: 0000000000200000 R15: 00007f4a4dc163a0
</TASK>
------------[ cut here ]------------
Voluntary context switch within RCU read-side critical section!
WARNING: kernel/rcu/tree_plugin.h:332 at rcu_note_context_switch+0xcac/0xf40 kernel/rcu/tree_plugin.h:332, CPU#0: syz-executor/5809
Modules linked in:
CPU: 0 UID: 0 PID: 5809 Comm: syz-executor Tainted: G W syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
RIP: 0010:rcu_note_context_switch+0xcac/0xf40 kernel/rcu/tree_plugin.h:332
Code: 00 41 c6 45 00 00 48 8b 3d 81 5e e2 0d 48 81 c4 b8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d e9 9b 60 ff ff 48 8d 3d f4 26 e6 0d <67> 48 0f b9 3a e9 1b f4 ff ff 90 0f 0b 90 45 84 e4 0f 84 ea f3 ff
RSP: 0018:ffffc900043b6fb0 EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff88803906bd80 RCX: 0000000080000002
RDX: 0000000000000000 RSI: ffffffff8ba83740 RDI: ffffffff8f907b60
RBP: dffffc0000000000 R08: ffffffff8f8d05f7 R09: 1ffffffff1f1a0be
R10: dffffc0000000000 R11: fffffbfff1f1a0bf R12: 0000000000000000
R13: ffff88803906bd80 R14: ffff8880b883c980 R15: ffff88803906c244
FS: 0000555571f48540(0000) GS:ffff8881260c2000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f64ae81e7b8 CR3: 000000001a1e4000 CR4: 00000000003526f0
Call Trace:
<TASK>
__schedule+0x297/0x54f0 kernel/sched/core.c:7043
__schedule_loop kernel/sched/core.c:7267 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7282
schedule_timeout+0x158/0x2c0 kernel/time/sleep_timeout.c:99
io_schedule_timeout+0x88/0xe0 kernel/sched/core.c:8097
do_wait_for_common kernel/sched/completion.c:100 [inline]
__wait_for_common kernel/sched/completion.c:121 [inline]
wait_for_common_io+0x2d7/0x610 kernel/sched/completion.c:138
blk_wait_io block/blk.h:102 [inline]
bio_await block/bio.c:1496 [inline]
submit_bio_wait+0x16d/0x250 block/bio.c:1513
blkdev_issue_flush+0xe0/0x150 block/blk-flush.c:475
ext4_sync_file+0x8b6/0xd60 fs/ext4/fsync.c:179
iomap_swapfile_activate+0x1e4/0xbe0 fs/iomap/swapfile.c:162
setup_swap_extents+0x176/0x640 mm/swapfile.c:2890
__do_sys_swapon mm/swapfile.c:3630 [inline]
__se_sys_swapon+0xdc9/0x2010 mm/swapfile.c:3539
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4a4d9cc7d7
Code: 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 a7 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc336ba3b8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a7
RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007f4a4d9cc7d7
RDX: 0000000000000000 RSI: 0000000000008000 RDI: 00007f4a4da62e5b
RBP: 00007f4a4da62e5b R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000008 R11: 0000000000000246 R12: 00007f4a4dc163e0
R13: 00007f4a4da7dd26 R14: 0000000000200000 R15: 00007f4a4dc163a0
</TASK>
----------------
Code disassembly (best guess):
0: 00 41 c6 add %al,-0x3a(%rcx)
3: 45 00 00 add %r8b,(%r8)
6: 48 8b 3d 81 5e e2 0d mov 0xde25e81(%rip),%rdi # 0xde25e8e
d: 48 81 c4 b8 00 00 00 add $0xb8,%rsp
14: 5b pop %rbx
15: 41 5c pop %r12
17: 41 5d pop %r13
19: 41 5e pop %r14
1b: 41 5f pop %r15
1d: 5d pop %rbp
1e: e9 9b 60 ff ff jmp 0xffff60be
23: 48 8d 3d f4 26 e6 0d lea 0xde626f4(%rip),%rdi # 0xde6271e
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: e9 1b f4 ff ff jmp 0xfffff44f
34: 90 nop
35: 0f 0b ud2
37: 90 nop
38: 45 84 e4 test %r12b,%r12b
3b: 0f .byte 0xf
3c: 84 ea test %ch,%dl
3e: f3 repz
3f: ff .byte 0xff
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [RFC PATCH 4/4] firmware: arm_ffa: check pkvm initailised when initailise ffa driver
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
In-Reply-To: <20260417175759.3191279-1-yeoreum.yun@arm.com>
When pKVM is enabled, the FF-A driver must be initialized after pKVM.
Otherwise, pKVM cannot negotiate the FF-A version or
obtain RX/TX buffer information, leading to failures in FF-A calls.
During FF-A driver initialization, check whether pKVM has been initialized.
If not, defer probing of the FF-A driver.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
arch/arm64/kvm/arm.c | 1 +
drivers/firmware/arm_ffa/driver.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 410ffd41fd73..0f517b1c05cd 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -119,6 +119,7 @@ bool is_kvm_arm_initialised(void)
{
return kvm_arm_initialised;
}
+EXPORT_SYMBOL(is_kvm_arm_initialised);
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
{
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 02c76ac1570b..2647d6554afd 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -42,6 +42,8 @@
#include <linux/uuid.h>
#include <linux/xarray.h>
+#include <asm/virt.h>
+
#include "common.h"
#define FFA_DRIVER_VERSION FFA_VERSION_1_2
@@ -2035,6 +2037,16 @@ static int __init ffa_init(void)
u32 buf_sz;
size_t rxtx_bufsz = SZ_4K;
+ /*
+ * When pKVM is enabled, the FF-A driver must be initialized
+ * after pKVM initialization. Otherwise, pKVM cannot negotiate
+ * the FF-A version or obtain RX/TX buffer information,
+ * which leads to failures in FF-A calls.
+ */
+ if (IS_ENABLED(CONFIG_KVM) && is_protected_kvm_enabled() &&
+ !is_kvm_arm_initialised())
+ return -EPROBE_DEFER;
+
ret = ffa_transport_init(&invoke_ffa_fn);
if (ret)
return ret;
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
* [RFC PATCH 3/4] firmware: arm_ffa: revert ffa_init() initcall level to device_initcall
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
In-Reply-To: <20260417175759.3191279-1-yeoreum.yun@arm.com>
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.
However, this introduces a problem: pKVM fails to handle any FF-A calls
because it cannot trap the FFA_VERSION call invoked by ffa_init().
Since the IMA init function level has been changed to late_initcall_sync,
there is no longer a need to keep ffa_init() at rootfs_initcall.
Revert it back to device_initcall.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index f2f94d4d533e..02c76ac1570b 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2106,7 +2106,7 @@ static int __init ffa_init(void)
kfree(drv_info);
return ret;
}
-rootfs_initcall(ffa_init);
+device_initcall(ffa_init);
static void __exit ffa_exit(void)
{
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
* [RFC PATCH 2/4] tpm: tpm_crb_ffa: revert defered_probed when tpm_crb_ffa 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
In-Reply-To: <20260417175759.3191279-1-yeoreum.yun@arm.com>
commit 746d9e9f62a6 ("tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's build_in")
probe tpm_crb_ffa forcefully when it's built-in to integrate with IMA.
However, as IMA init function is changed to late_initcall_sync level.
So, this change isn't required anymore.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
drivers/char/tpm/tpm_crb_ffa.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
index 99f1c1e5644b..025c4d4b17ca 100644
--- a/drivers/char/tpm/tpm_crb_ffa.c
+++ b/drivers/char/tpm/tpm_crb_ffa.c
@@ -177,23 +177,13 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
*/
int tpm_crb_ffa_init(void)
{
- int ret = 0;
-
- if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
- ret = ffa_register(&tpm_crb_ffa_driver);
- if (ret) {
- tpm_crb_ffa = ERR_PTR(-ENODEV);
- return ret;
- }
- }
-
if (!tpm_crb_ffa)
- ret = -ENOENT;
+ return -ENOENT;
if (IS_ERR_VALUE(tpm_crb_ffa))
- ret = -ENODEV;
+ return -ENODEV;
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
@@ -405,9 +395,7 @@ static struct ffa_driver tpm_crb_ffa_driver = {
.id_table = tpm_crb_ffa_device_id,
};
-#ifdef MODULE
module_ffa_driver(tpm_crb_ffa_driver);
-#endif
MODULE_AUTHOR("Arm");
MODULE_DESCRIPTION("TPM CRB FFA driver");
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
* [RFC PATCH 1/4] security: ima: move ima_init into late_initcall_sync
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
In-Reply-To: <20260417175759.3191279-1-yeoreum.yun@arm.com>
To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
the TPM driver must be built as built-in and
must be probed before the IMA subsystem is initialized.
However, when the TPM device operates over the FF-A protocol using
the CRB interface, probing fails and returns -EPROBE_DEFER if
the tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.
To ensure the TPM device operating over the FF-A protocol with
the CRB interface is probed before IMA initialization,
the following conditions must be met:
1. The corresponding ffa_device must be registered,
which is done via ffa_init().
2. The tpm_crb_driver must successfully probe this device via
tpm_crb_ffa_init().
3. The tpm_crb driver using CRB over FF-A can then
be probed successfully. (See crb_acpi_add() and
tpm_crb_ffa_init() for reference.)
Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
all registered with device_initcall, which means crb_acpi_driver_init() may
be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
When this occurs, probing the TPM device is deferred.
However, the deferred probe can happen after the IMA subsystem
has already been initialized, since IMA initialization is performed
during late_initcall, and deferred_probe_initcall() is performed
at the same level.
To resolve this, move ima_init() into late_inicall_sync level
so that let IMA not miss TPM PCR value when generating boot_aggregate
log though TPM device presents in the system.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
include/linux/lsm_hooks.h | 2 ++
security/integrity/ima/ima_main.c | 2 +-
security/lsm_init.c | 13 +++++++++++--
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index d48bf0ad26f4..88fe105b7f00 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -166,6 +166,7 @@ enum lsm_order {
* @initcall_fs: LSM callback for fs_initcall setup, optional
* @initcall_device: LSM callback for device_initcall() setup, optional
* @initcall_late: LSM callback for late_initcall() setup, optional
+ * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
*/
struct lsm_info {
const struct lsm_id *id;
@@ -181,6 +182,7 @@ struct lsm_info {
int (*initcall_fs)(void);
int (*initcall_device)(void);
int (*initcall_late)(void);
+ int (*initcall_late_sync)(void);
};
#define DEFINE_LSM(lsm) \
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 1d6229b156fb..ace280fa3212 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -1320,5 +1320,5 @@ DEFINE_LSM(ima) = {
.order = LSM_ORDER_LAST,
.blobs = &ima_blob_sizes,
/* Start IMA after the TPM is available */
- .initcall_late = init_ima,
+ .initcall_late_sync = init_ima,
};
diff --git a/security/lsm_init.c b/security/lsm_init.c
index 573e2a7250c4..4e5c59beb82a 100644
--- a/security/lsm_init.c
+++ b/security/lsm_init.c
@@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
* security_initcall_late - Run the LSM late initcalls
*/
static int __init security_initcall_late(void)
+{
+ return lsm_initcall(late);
+}
+late_initcall(security_initcall_late);
+
+/**
+ * security_initcall_late_sync - Run the LSM late initcalls sync
+ */
+static int __init security_initcall_late_sync(void)
{
int rc;
- rc = lsm_initcall(late);
+ rc = lsm_initcall(late_sync);
lsm_pr_dbg("all enabled LSMs fully activated\n");
call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
return rc;
}
-late_initcall(security_initcall_late);
+late_initcall_sync(security_initcall_late_sync);
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
* [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
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