kernel/linux.git/security/integrity/ima, 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

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

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

ima_fs: get rid of lookup-by-dentry stuff

2025-06-17T22:10:14+00:00

lookup_template_data_hash_algo() machinery is used to locate the matching ima_algo_array[] element at read time; securityfs allows to stash that into inode->i_private at object creation time, so there's no need to bother Acked-by: Mimi Zohar Signed-off-by: Al Viro

ima_fs: don't bother with removal of files in directory we'll be removing

2025-06-17T22:09:52+00:00

removal of parent takes all children out Acked-by: Mimi Zohar Signed-off-by: Al Viro

ima: add a knob ima= to allow disabling IMA in kdump kernel

2025-06-16T13:15:13+00:00

Kdump kernel doesn't need IMA functionality, and enabling IMA will cost extra memory. It would be very helpful to allow IMA to be disabled for kdump kernel. Hence add a knob ima=on|off here to allow turning IMA off in kdump kernel if needed. Note that this IMA disabling is limited to kdump kernel, please don't abuse it in other kernel and thus serious consequences are caused. Signed-off-by: Baoquan He Signed-off-by: Mimi Zohar

ima: do not copy measurement list to kdump kernel

2025-05-14T10:40:09+00:00

Kdump kernel doesn't need IMA to do integrity measurement. Hence the measurement list in 1st kernel doesn't need to be copied to kdump kernel. Here skip allocating buffer for measurement list copying if loading kdump kernel. Then there won't be the later handling related to ima_kexec_buffer. Signed-off-by: Steven Chen Tested-by: Baoquan He Acked-by: Baoquan He Signed-off-by: Mimi Zohar