linux.git/security/integrity/ima, branch v6.12.80

ima: verify the previous kernel's IMA buffer lies in addressable RAM

2026-03-13T16:20:27+00:00

[ Upstream commit 10d1c75ed4382a8e79874379caa2ead8952734f9 ]

Patch series "Address page fault in ima_restore_measurement_list()", v3.

When the second-stage kernel is booted via kexec with a limiting command
line such as "mem=" we observe a pafe fault that happens.

    BUG: unable to handle page fault for address: ffff97793ff47000
    RIP: ima_restore_measurement_list+0xdc/0x45a
    #PF: error_code(0x0000)  not-present page

This happens on x86_64 only, as this is already fixed in aarch64 in
commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer
against memory bounds")

This patch (of 3):

When the second-stage kernel is booted with a limiting command line (e.g.
"mem="), the IMA measurement buffer handed over from the previous
kernel may fall outside the addressable RAM of the new kernel.  Accessing
such a buffer can fault during early restore.

Introduce a small generic helper, ima_validate_range(), which verifies
that a physical [start, end] range for the previous-kernel IMA buffer lies
within addressable memory:
	- On x86, use pfn_range_is_mapped().
	- On OF based architectures, use page_is_ram().

Link: https://lkml.kernel.org/r/20251231061609.907170-1-harshit.m.mogalapalli@oracle.com
Link: https://lkml.kernel.org/r/20251231061609.907170-2-harshit.m.mogalapalli@oracle.com
Signed-off-by: Harshit Mogalapalli 
Reviewed-by: Mimi Zohar 
Cc: Alexander Graf 
Cc: Ard Biesheuvel 
Cc: Borislav Betkov 
Cc: guoweikang 
Cc: Henry Willard 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jiri Bohac 
Cc: Joel Granados 
Cc: Jonathan McDowell 
Cc: Mike Rapoport 
Cc: Paul Webb 
Cc: Sohil Mehta 
Cc: Sourabh Jain 
Cc: Thomas Gleinxer 
Cc: Yifei Liu 
Cc: Baoquan He 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

ima: kexec: define functions to copy IMA log at soft boot

2026-03-13T16:20:27+00:00

[ Upstream commit f18e502db673c75f762d47101dafcf58f30e2733 ]

The IMA log is currently copied to the new kernel during kexec 'load'
using ima_dump_measurement_list(). However, the log copied at kexec
'load' may result in loss of IMA measurements that only occurred after
kexec "load'. Setup the needed infrastructure to move the IMA log copy
from kexec 'load' to 'execute'.

Define a new IMA hook ima_update_kexec_buffer() as a stub function.
It will be used to call ima_dump_measurement_list() during kexec 'execute'.

Implement ima_kexec_post_load() function to be invoked after the new
Kernel image has been loaded for kexec. ima_kexec_post_load() maps the
IMA buffer to a segment in the newly loaded Kernel.  It also registers
the reboot notifier_block to trigger ima_update_kexec_buffer() at
kexec 'execute'.

Set the priority of register_reboot_notifier to INT_MIN to ensure that the
IMA log copy operation will happen at the end of the operation chain, so
that all the IMA measurement records extended into the TPM are copied

Co-developed-by: Tushar Sugandhi 
Signed-off-by: Tushar Sugandhi 
Cc: Eric Biederman 
Cc: Baoquan He 
Cc: Vivek Goyal 
Cc: Dave Young 
Signed-off-by: Steven Chen 
Reviewed-by: Stefan Berger 
Acked-by: Baoquan He 
Tested-by: Stefan Berger  # ppc64/kvm
Signed-off-by: Mimi Zohar 
Stable-dep-of: 10d1c75ed438 ("ima: verify the previous kernel's IMA buffer lies in addressable RAM")
Signed-off-by: Sasha Levin

ima: define and call ima_alloc_kexec_file_buf()

2026-03-13T16:20:27+00:00

[ Upstream commit c95e1acb6d7f00efab73e41b31e0560751e3f469 ]

In the current implementation, the ima_dump_measurement_list() API is
called during the kexec "load" phase, where a buffer is allocated and
the measurement records are copied. Due to this, new events added after
kexec load but before kexec execute are not carried over to the new kernel
during kexec operation

Carrying the IMA measurement list across kexec requires allocating a
buffer and copying the measurement records.  Separate allocating the
buffer and copying the measurement records into separate functions in
order to allocate the buffer at kexec 'load' and copy the measurements
at kexec 'execute'.

After moving the vfree() here at this stage in the patch set, the IMA
measurement list fails to verify when doing two consecutive "kexec -s -l"
with/without a "kexec -s -u" in between.  Only after "ima: kexec: move
IMA log copy from kexec load to execute" the IMA measurement list verifies
properly with the vfree() here.

Co-developed-by: Tushar Sugandhi 
Signed-off-by: Tushar Sugandhi 
Signed-off-by: Steven Chen 
Reviewed-by: Stefan Berger 
Acked-by: Baoquan He 
Tested-by: Stefan Berger  # ppc64/kvm
Signed-off-by: Mimi Zohar 
Stable-dep-of: 10d1c75ed438 ("ima: verify the previous kernel's IMA buffer lies in addressable RAM")
Signed-off-by: Sasha Levin

ima: rename variable the seq_file "file" to "ima_kexec_file"

2026-03-13T16:20:27+00:00

[ Upstream commit cb5052282c65dc998d12e4eea8d5133249826c13 ]

Before making the function local seq_file "file" variable file static
global, rename it to "ima_kexec_file".

Signed-off-by: Steven Chen 
Acked-by: Baoquan He 
Tested-by: Stefan Berger  # ppc64/kvm
Signed-off-by: Mimi Zohar 
Stable-dep-of: 10d1c75ed438 ("ima: verify the previous kernel's IMA buffer lies in addressable RAM")
Signed-off-by: Sasha Levin

ima: kexec: silence RCU list traversal warning

2026-03-13T16:20:27+00:00

[ Upstream commit 68af44a71975688b881ea524e2526bb7c7ad0e9a ]

The ima_measurements list is append-only and doesn't require
rcu_read_lock() protection. However, lockdep issues a warning when
traversing RCU lists without the read lock:

  security/integrity/ima/ima_kexec.c:40 RCU-list traversed in non-reader section!!

Fix this by using the variant of list_for_each_entry_rcu() with the last
argument set to true. This tells the RCU subsystem that traversing this
append-only list without the read lock is intentional and safe.

This change silences the lockdep warning while maintaining the correct
semantics for the append-only list traversal.

Signed-off-by: Breno Leitao 
Signed-off-by: Mimi Zohar 
Stable-dep-of: 10d1c75ed438 ("ima: verify the previous kernel's IMA buffer lies in addressable RAM")
Signed-off-by: Sasha Levin

ima: Handle error code returned by ima_filter_rule_match()

2025-12-18T12:55:04+00:00

[ Upstream commit 738c9738e690f5cea24a3ad6fd2d9a323cf614f6 ]

In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due to
the rule being NULL, the function incorrectly skips the 'if (!rc)' check
and sets 'result = true'. The LSM rule is considered a match, causing
extra files to be measured by IMA.

This issue can be reproduced in the following scenario:
After unloading the SELinux policy module via 'semodule -d', if an IMA
measurement is triggered before ima_lsm_rules is updated,
in ima_match_rules(), the first call to ima_filter_rule_match() returns
-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&
!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. In
ima_lsm_copy_rule(), since the SELinux module has been removed, the rule
becomes NULL, and the second call to ima_filter_rule_match() returns
-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.

Call trace:
  selinux_audit_rule_match+0x310/0x3b8
  security_audit_rule_match+0x60/0xa0
  ima_match_rules+0x2e4/0x4a0
  ima_match_policy+0x9c/0x1e8
  ima_get_action+0x48/0x60
  process_measurement+0xf8/0xa98
  ima_bprm_check+0x98/0xd8
  security_bprm_check+0x5c/0x78
  search_binary_handler+0x6c/0x318
  exec_binprm+0x58/0x1b8
  bprm_execve+0xb8/0x130
  do_execveat_common.isra.0+0x1a8/0x258
  __arm64_sys_execve+0x48/0x68
  invoke_syscall+0x50/0x128
  el0_svc_common.constprop.0+0xc8/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x44/0x200
  el0t_64_sync_handler+0x100/0x130
  el0t_64_sync+0x3c8/0x3d0

Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that error
codes like -ENOENT do not bypass the check and accidentally result in a
successful match.

Fixes: 4af4662fa4a9d ("integrity: IMA policy")
Signed-off-by: Zhao Yipeng 
Reviewed-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

2025-11-13T20:34:32+00:00

[ Upstream commit 88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd ]

Currently when both IMA and EVM are in fix mode, the IMA signature will
be reset to IMA hash if a program first stores IMA signature in
security.ima and then writes/removes some other security xattr for the
file.

For example, on Fedora, after booting the kernel with "ima_appraise=fix
evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,
installing/reinstalling a package will not make good reference IMA
signature generated. Instead IMA hash is generated,

    # getfattr -m - -d -e hex /usr/bin/bash
    # file: usr/bin/bash
    security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag
that had been set early was cleared. As a result, IMA hash is generated
when the file is closed.

Similarly, IMA signature can be cleared on file close after removing
security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing
the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last
step which can also replaced by removing security.evm or setting ACL,

    #include 
    #include 
    #include 
    #include 
    #include 
    #include 

    int main() {
        const char* file_path = "/usr/sbin/test_binary";
        const char* hex_string = "030204d33204490066306402304";
        int length = strlen(hex_string);
        char* ima_attr_value;
        int fd;

        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
        if (fd == -1) {
            perror("Error opening file");
            return 1;
        }

        ima_attr_value = (char*)malloc(length / 2 );
        for (int i = 0, j = 0; i < length; i += 2, j++) {
            sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);
        }

        if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {
            perror("Error setting extended attribute");
            close(fd);
            return 1;
        }

        const char* selinux_value= "system_u:object_r:bin_t:s0";
        if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {
            perror("Error setting extended attribute");
            close(fd);
            return 1;
        }

        close(fd);

        return 0;
    }

Signed-off-by: Coiby Xu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: process_measurement() needlessly takes inode_lock() on MAY_READ

2025-05-29T09:02:00+00:00

[ Upstream commit 30d68cb0c37ebe2dc63aa1d46a28b9163e61caa2 ]

On IMA policy update, if a measure rule exists in the policy,
IMA_MEASURE is set for ima_policy_flags which makes the violation_check
variable always true. Coupled with a no-action on MAY_READ for a
FILE_CHECK call, we're always taking the inode_lock().

This becomes a performance problem for extremely heavy read-only workloads.
Therefore, prevent this only in the case there's no action to be taken.

Signed-off-by: Frederick Lawler 
Acked-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: limit the number of ToMToU integrity violations

2025-04-20T08:15:43+00:00

commit a414016218ca97140171aa3bb926b02e1f68c2cc upstream.

Each time a file in policy, that is already opened for read, is opened
for write, a Time-of-Measure-Time-of-Use (ToMToU) integrity violation
audit message is emitted and a violation record is added to the IMA
measurement list.  This occurs even if a ToMToU violation has already
been recorded.

Limit the number of ToMToU integrity violations per file open for read.

Note: The IMA_MAY_EMIT_TOMTOU atomic flag must be set from the reader
side based on policy.  This may result in a per file open for read
ToMToU violation.

Since IMA_MUST_MEASURE is only used for violations, rename the atomic
IMA_MUST_MEASURE flag to IMA_MAY_EMIT_TOMTOU.

Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6
Tested-by: Stefan Berger 
Reviewed-by: Petr Vorel 
Tested-by: Petr Vorel 
Reviewed-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman

ima: limit the number of open-writers integrity violations

2025-04-20T08:15:43+00:00

commit 5b3cd801155f0b34b0b95942a5b057c9b8cad33e upstream.

Each time a file in policy, that is already opened for write, is opened
for read, an open-writers integrity violation audit message is emitted
and a violation record is added to the IMA measurement list. This
occurs even if an open-writers violation has already been recorded.

Limit the number of open-writers integrity violations for an existing
file open for write to one.  After the existing file open for write
closes (__fput), subsequent open-writers integrity violations may be
emitted.

Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6
Tested-by: Stefan Berger 
Reviewed-by: Petr Vorel 
Tested-by: Petr Vorel 
Reviewed-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman