linux.git/security/integrity, branch v6.18.21

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

2026-03-04T12:21:17+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

evm: Use ordered xattrs list to calculate HMAC in evm_init_hmac()

2026-02-26T22:59:14+00:00

[ Upstream commit 0496fc9cdc384f67be4413b1c6156eb64fccd5c4 ]

Commit 8e5d9f916a96 ("smack: deduplicate xattr setting in
smack_inode_init_security()") introduced xattr_dupval() to simplify setting
the xattrs to be provided by the SMACK LSM on inode creation, in the
smack_inode_init_security().

Unfortunately, moving lsm_get_xattr_slot() caused the SMACK64TRANSMUTE
xattr be added in the array of new xattrs before SMACK64. This causes the
HMAC of xattrs calculated by evm_init_hmac() for new files to diverge from
the one calculated by both evm_calc_hmac_or_hash() and evmctl.

evm_init_hmac() calculates the HMAC of the xattrs of new files based on the
order LSMs provide them, while evm_calc_hmac_or_hash() and evmctl calculate
the HMAC based on an ordered xattrs list.

Fix the issue by making evm_init_hmac() calculate the HMAC of new files
based on the ordered xattrs list too.

Fixes: 8e5d9f916a96 ("smack: deduplicate xattr setting in smack_inode_init_security()")
Signed-off-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

kernel/kexec: change the prototype of kimage_map_segment()

2026-01-08T09:17:10+00:00

commit fe55ea85939efcbf0e6baa234f0d70acb79e7b58 upstream.

The kexec segment index will be required to extract the corresponding
information for that segment in kimage_map_segment().  Additionally,
kexec_segment already holds the kexec relocation destination address and
size.  Therefore, the prototype of kimage_map_segment() can be changed.

Link: https://lkml.kernel.org/r/20251216014852.8737-1-piliu@redhat.com
Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
Signed-off-by: Pingfan Liu 
Acked-by: Baoquan He 
Cc: Mimi Zohar 
Cc: Roberto Sassu 
Cc: Alexander Graf 
Cc: Steven Chen 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

ima: Handle error code returned by ima_filter_rule_match()

2025-12-18T13:03:10+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: Attach CREDS_CHECK IMA hook to bprm_creds_from_file LSM hook

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

[ Upstream commit 8f3fc4f3f8aa6e99266c69cc78bdaa58379e65fc ]

Since commit 56305aa9b6fa ("exec: Compute file based creds only once"), the
credentials to be applied to the process after execution are not calculated
anymore for each step of finding intermediate interpreters (including the
final binary), but only after the final binary to be executed without
interpreter has been found.

In particular, that means that the bprm_check_security LSM hook will not
see the updated cred->e[ug]id for the intermediate and for the final binary
to be executed, since the function doing this task has been moved from
prepare_binprm(), which calls the bprm_check_security hook, to
bprm_creds_from_file().

This breaks the IMA expectation for the CREDS_CHECK hook, introduced with
commit d906c10d8a31 ("IMA: Support using new creds in appraisal policy"),
which expects to evaluate "the credentials that will be committed when the
new process is started". This is clearly not the case for the CREDS_CHECK
IMA hook, which is attached to bprm_check_security.

This issue does not affect systems which load a policy with the BPRM_CHECK
hook with no other criteria, as is the case with the built-in "tcb" and/or
"appraise_tcb" IMA policies. The "tcb" built-in policy measures all
executions regardless of the new credentials, and the "appraise_tcb" policy
is written in terms of the file owner, rather than IMA hooks.

However, it does affect systems without a BPRM_CHECK policy rule or with a
BPRM_CHECK policy rule that does not include what CREDS_CHECK evaluates. As
an extreme example, taking a standalone rule like:

measure func=CREDS_CHECK euid=0

This will not measure for example sudo (because CREDS_CHECK still sees the
bprm->cred->euid set to the regular user UID), but only the subsequent
commands after the euid was applied to the children.

Make set[ug]id programs measured/appraised again by splitting
ima_bprm_check() in two separate hook implementations (CREDS_CHECK now
being implemented by ima_creds_check()), and by attaching CREDS_CHECK to
the bprm_creds_from_file LSM hook.

The limitation of this approach is that CREDS_CHECK will not be invoked
anymore for the intermediate interpreters, like it was before, but only for
the final binary. This limitation can be removed only by reverting commit
56305aa9b6fa ("exec: Compute file based creds only once").

Link: https://github.com/linux-integrity/linux/issues/3
Fixes: 56305aa9b6fa ("exec: Compute file based creds only once")
Cc: Serge E. Hallyn 
Cc: Matthew Garrett 
Cc: Eric W. Biederman 
Cc: Jann Horn 
Cc: Christian Brauner 
Cc: Kees Cook 
Signed-off-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-10-03T11:50:56+00:00

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

integrity: Select CRYPTO from INTEGRITY_ASYMMETRIC_KEYS

2025-10-03T11:50:56+00:00

Select CRYPTO from INTEGRITY_ASYMMETRIC_KEYS, since
INTEGRITY_ASYMMETRIC_KEYS selects several options that depend on CRYPTO.

This unblocks the removal of the CRYPTO selection from SIGNATURE.
SIGNATURE (lib/digsig.c) itself will no longer need CRYPTO, but
INTEGRITY_ASYMMETRIC_KEYS was depending on it indirectly via the chain
SIGNATURE => INTEGRITY_SIGNATURE => INTEGRITY_ASYMMETRIC_KEYS.

Signed-off-by: Eric Biggers 
Reviewed-by: Paul Menzel 
Signed-off-by: Mimi Zohar

Merge tag 'integrity-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

2025-07-31T18:42:11+00:00

Pull integrity update from Mimi Zohar:
 "A single commit to permit disabling IMA from the boot command line for
  just the kdump kernel.

  The exception itself sort of makes sense. My concern is that
  exceptions do not remain as exceptions, but somehow morph to become
  the norm"

* tag 'integrity-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
  ima: add a knob ima= to allow disabling IMA in kdump kernel

Merge tag 'powerpc-6.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2025-07-30T03:28:38+00:00

Pull powerpc updates from Madhavan Srinivasan:

 - CONFIG_HZ changes to move the base_slice from 10ms to 1ms

 - Patchset to move some of the mutex handling to lock guard

 - Expose secvars relevant to the key management mode

 - Misc cleanups and fixes

Thanks to Ankit Chauhan, Christophe Leroy, Donet Tom, Gautam Menghani,
Haren Myneni, Johan Korsnes, Madadi Vineeth Reddy, Paul Mackerras,
Shrikanth Hegde, Srish Srinivasan, Thomas Fourier, Thomas Huth, Thomas
Weißschuh, Souradeep, Amit Machhiwal, R Nageswara Sastry, Venkat Rao
Bagalkote, Andrew Donnellan, Greg Kroah-Hartman, Mimi Zohar, Mukesh
Kumar Chaurasiya, Nayna Jain, Ritesh Harjani (IBM), Sourabh Jain, Srikar
Dronamraju, Stefan Berger, Tyrel Datwyler, and Kowshik Jois.

* tag 'powerpc-6.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (23 commits)
  arch/powerpc: Remove .interp section in vmlinux
  powerpc: Drop GPL boilerplate text with obsolete FSF address
  powerpc: Don't use %pK through printk
  arch: powerpc: defconfig: Drop obsolete CONFIG_NET_CLS_TCINDEX
  misc: ocxl: Replace scnprintf() with sysfs_emit() in sysfs show functions
  integrity/platform_certs: Allow loading of keys in the static key management mode
  powerpc/secvar: Expose secvars relevant to the key management mode
  powerpc/pseries: Correct secvar format representation for static key management
  (powerpc/512) Fix possible `dma_unmap_single()` on uninitialized pointer
  powerpc: floppy: Add missing checks after DMA map
  book3s64/radix : Optimize vmemmap start alignment
  book3s64/radix : Handle error conditions properly in radix_vmemmap_populate
  powerpc/pseries/dlpar: Search DRC index from ibm,drc-indexes for IO add
  KVM: PPC: Book3S HV: Add H_VIRT mapping for tracing exits
  powerpc: sysdev: use lock guard for mutex
  powerpc: powernv: ocxl: use lock guard for mutex
  powerpc: book3s: vas: use lock guard for mutex
  powerpc: fadump: use lock guard for mutex
  powerpc: rtas: use lock guard for mutex
  powerpc: eeh: use lock guard for mutex
  ...

integrity/platform_certs: Allow loading of keys in the static key management mode

2025-07-09T03:46:18+00:00

On PLPKS enabled PowerVM LPAR, there is no provision to load signed
third-party kernel modules when the key management mode is static. This
is because keys from secure boot secvars are only loaded when the key
management mode is dynamic.

Allow loading of the trustedcadb and moduledb keys even in the static
key management mode, where the secvar format string takes the form
"ibm,plpks-sb-v0".

Signed-off-by: Srish Srinivasan 
Tested-by: R Nageswara Sastry 
Reviewed-by: Mimi Zohar 
Reviewed-by: Stefan Berger 
Reviewed-by: Nayna Jain 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20250610211907.101384-4-ssrish@linux.ibm.com