linux-stable.git/security/integrity, branch v6.12.91

ima_fs: Correctly create securityfs files for unsupported hash algos

2026-05-23T11:04:40+00:00

[ Upstream commit d7bd8cf0b348d3edae7bee33e74a32b21668b181 ]

ima_tpm_chip->allocated_banks[i].crypto_id is initialized to
HASH_ALGO__LAST if the TPM algorithm is not supported. However there
are places relying on the algorithm to be valid because it is accessed
by hash_algo_name[].

On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
  ==================================================================
  BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
  Read of size 8 at addr ffffffff83e18138 by task swapper/0/1

  CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
  Call Trace:
   
   dump_stack_lvl+0x61/0x90
   print_report+0xc4/0x580
   ? kasan_addr_to_slab+0x26/0x80
   ? create_securityfs_measurement_lists+0x396/0x440
   kasan_report+0xc2/0x100
   ? create_securityfs_measurement_lists+0x396/0x440
   create_securityfs_measurement_lists+0x396/0x440
   ima_fs_init+0xa3/0x300
   ima_init+0x7d/0xd0
   init_ima+0x28/0x100
   do_one_initcall+0xa6/0x3e0
   kernel_init_freeable+0x455/0x740
   kernel_init+0x24/0x1d0
   ret_from_fork+0x38/0x80
   ret_from_fork_asm+0x11/0x20
   

  The buggy address belongs to the variable:
   hash_algo_name+0xb8/0x420

  Memory state around the buggy address:
   ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
   ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
                                          ^
   ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
   ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
  ==================================================================

Seems like the TPM chip supports sha3_256, which isn't yet in
tpm_algorithms:
  tpm tpm0: TPM with unsupported bank algorithm 0x0027

That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0
Library Part 2: Structures", page 51 [1].
See also the related U-Boot algorithms update [2].

Thus solve the problem by creating a file name with "_tpm_alg_"
postfix if the crypto algorithm isn't initialized.

This is how it looks on the test machine (patch ported to v6.12 release):
  # ls -1 /sys/kernel/security/ima/
  ascii_runtime_measurements
  ascii_runtime_measurements_tpm_alg_27
  ascii_runtime_measurements_sha1
  ascii_runtime_measurements_sha256
  binary_runtime_measurements
  binary_runtime_measurements_tpm_alg_27
  binary_runtime_measurements_sha1
  binary_runtime_measurements_sha256
  policy
  runtime_measurements_count
  violations

[1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf
[2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html

Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
Signed-off-by: Dmitry Safonov 
Cc: Enrico Bravi 
Cc: Silvia Sisinni 
Cc: Roberto Sassu 
Cc: Mimi Zohar 
Reviewed-by: Roberto Sassu 
Tested-by: Roberto Sassu 
Link: https://github.com/linux-integrity/linux/issues/14
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima_fs: get rid of lookup-by-dentry stuff

2026-05-23T11:04:40+00:00

[ Upstream commit d15ffbbf4d32a9007c4a339a9fecac90ce30432a ]

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 
Stable-dep-of: d7bd8cf0b348 ("ima_fs: Correctly create securityfs files for unsupported hash algos")
Signed-off-by: Sasha Levin

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

2026-05-23T11:04:40+00:00

[ Upstream commit 22260a99d791163f7697a240dfc48e4e5a91ecfe ]

removal of parent takes all children out

Acked-by: Mimi Zohar 
Signed-off-by: Al Viro 
Stable-dep-of: d7bd8cf0b348 ("ima_fs: Correctly create securityfs files for unsupported hash algos")
Signed-off-by: Sasha Levin

ima: check return value of crypto_shash_final() in boot aggregate

2026-05-23T11:04:40+00:00

[ Upstream commit 870819434c8dfcc3158033b66e7851b81bb17e21 ]

The return value of crypto_shash_final() is not checked in
ima_calc_boot_aggregate_tfm(). If the hash finalization fails, the
function returns success and a corrupted boot aggregate digest could
be used for IMA measurements.

Capture the return value and propagate any error to the caller.

Fixes: 76bb28f6126f ("ima: use new crypto_shash API instead of old crypto_hash")
Signed-off-by: Daniel Hodges 
Reviewed-by: Roberto Sassu 
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

ima: do not copy measurement list to kdump kernel

2026-04-27T13:24:24+00:00

[ Upstream commit fe3aebf27dc1875b2a0d13431e2e8cf3cf350cca ]

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 
Signed-off-by: Sasha Levin

ima: verify if the segment size has changed

2026-04-27T13:24:24+00:00

[ Upstream commit d0a00ce470e3ea19ba3b9f1c390aee739570a44a ]

kexec 'load' may be called multiple times. Free and realloc the buffer
only if the segment_size is changed from the previous kexec 'load' call.

Signed-off-by: Steven Chen 
Reviewed-by: Stefan Berger 
Acked-by: Baoquan He 
Tested-by: Stefan Berger  # ppc64/kvm
Signed-off-by: Mimi Zohar 
Signed-off-by: Sasha Levin

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