<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/security/integrity/ima/ima_crypto.c, branch linux-7.1.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.1.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.1.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-17T22:53:49+00:00</updated>
<entry>
<title>ima: remove buggy support for asynchronous hashes</title>
<updated>2026-03-17T22:53:49+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2026-03-12T05:39:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7a60fe48af206d34571e446d685672f5730a6b90'/>
<id>urn:sha1:7a60fe48af206d34571e446d685672f5730a6b90</id>
<content type='text'>
IMA computes hashes using the crypto_shash or crypto_ahash API.  The
latter is used only when ima.ahash_minsize is set on the command line,
and its purpose is ostensibly to make the hash computation faster.

However, going off the CPU to a crypto engine and back again is actually
quite slow, especially compared with the acceleration that is built into
modern CPUs and the kernel now enables by default for most algorithms.
Typical performance results for SHA-256 on a modern platform can be
found at https://lore.kernel.org/linux-crypto/20250615184638.GA1480@sol/

Partly for this reason, several other kernel subsystems have already
dropped support for the crypto_ahash API.

The other problem with crypto_ahash is that bugs are also common, not
just in the underlying drivers, but also in the code using it, since it
is very difficult to use correctly.  Just from a quick review, here are
some of the bugs I noticed in IMA's ahash code:

- [Use after free] ima_alloc_atfm() isn't thread-safe and can trigger a
  use-after-free if multiple threads try to initialize the global
  ima_ahash_tfm at the same time.

- [Deadlock] If only one buffer is allocated and there is an error
  reading from the file, then ahash_wait() is executed twice, causing a
  deadlock in wait_for_completion().

- [Crash or incorrect hash computed] calc_buffer_ahash_atfm() is
  sometimes passed stack buffers which can be vmalloc addresses, but it
  puts them in a scatterlist assuming they are linear addresses.  This
  causes the hashing to be done on the wrong physical address.

- [Truncation to 32-bit length] ima_alloc_pages() incorrectly assumes an
  loff_t value fits in an unsigned long.  calc_buffer_ahash_atfm()
  incorrectly assumes that a loff_t value fits in an unsigned int.

So, not exactly a great track record so far, even disregarding driver
bugs which are an even larger problem.  Fortunately, in practice it's
unlikely that many users are actually setting the ima.ahash_minsize
kernel command-line parameter which enables this code.  However, given
that this code is almost certainly no longer useful (if it ever was),
let's just remove it instead of attempting to fix all these issues.

Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Acked-by: Dmitry Kasatkin &lt;dmitry.kasatkin@gmail.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: check return value of crypto_shash_final() in boot aggregate</title>
<updated>2026-03-09T14:57:49+00:00</updated>
<author>
<name>Daniel Hodges</name>
<email>hodgesd@meta.com</email>
</author>
<published>2026-02-01T02:40:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=870819434c8dfcc3158033b66e7851b81bb17e21'/>
<id>urn:sha1:870819434c8dfcc3158033b66e7851b81bb17e21</id>
<content type='text'>
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 &lt;hodgesd@meta.com&gt;
Reviewed-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima: Define and use a digest_size field in the ima_algo_desc structure</title>
<updated>2026-03-08T12:26:08+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2026-02-27T12:06:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a74d7197ebe5b1b8028911d47e78c119d9aaf193'/>
<id>urn:sha1:a74d7197ebe5b1b8028911d47e78c119d9aaf193</id>
<content type='text'>
Add the digest_size field to the ima_algo_desc structure to determine the
digest size from the correct source.

If the hash algorithm is among allocated PCR banks, take the value from the
TPM bank info (equal to the value from the crypto subsystem if the TPM
algorithm is supported by it; otherwise, not exceding the size of the
digest buffer in the tpm_digest structure, used by IMA).

If the hash algorithm is SHA1, use the predefined value. Lastly, if the
hash algorithm is the default one but not among the PCR banks, take the
digest size from the crypto subsystem (the default hash algorithm is
checked when parsing the ima_hash= command line option).

Finally, use the new information to correctly show the template digest in
ima_measurements_show() and ima_ascii_measurements_show().

Link: https://github.com/linux-integrity/linux/issues/14
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses</title>
<updated>2026-02-22T16:26:33+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees@kernel.org</email>
</author>
<published>2026-02-22T07:46:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=189f164e573e18d9f8876dbd3ad8fcbe11f93037'/>
<id>urn:sha1:189f164e573e18d9f8876dbd3ad8fcbe11f93037</id>
<content type='text'>
Conversion performed via this Coccinelle script:

  // SPDX-License-Identifier: GPL-2.0-only
  // Options: --include-headers-for-types --all-includes --include-headers --keep-comments
  virtual patch

  @gfp depends on patch &amp;&amp; !(file in "tools") &amp;&amp; !(file in "samples")@
  identifier ALLOC = {kmalloc_obj,kmalloc_objs,kmalloc_flex,
 		    kzalloc_obj,kzalloc_objs,kzalloc_flex,
		    kvmalloc_obj,kvmalloc_objs,kvmalloc_flex,
		    kvzalloc_obj,kvzalloc_objs,kvzalloc_flex};
  @@

  	ALLOC(...
  -		, GFP_KERNEL
  	)

  $ make coccicheck MODE=patch COCCI=gfp.cocci

Build and boot tested x86_64 with Fedora 42's GCC and Clang:

Linux version 6.19.0+ (user@host) (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version 2.44-12.fc42) #1 SMP PREEMPT_DYNAMIC 1970-01-01
Linux version 6.19.0+ (user@host) (clang version 20.1.8 (Fedora 20.1.8-4.fc42), LLD 20.1.8) #1 SMP PREEMPT_DYNAMIC 1970-01-01

Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>treewide: Replace kmalloc with kmalloc_obj for non-scalar types</title>
<updated>2026-02-21T09:02:28+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees@kernel.org</email>
</author>
<published>2026-02-21T07:49:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69050f8d6d075dc01af7a5f2f550a8067510366f'/>
<id>urn:sha1:69050f8d6d075dc01af7a5f2f550a8067510366f</id>
<content type='text'>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook &lt;kees@kernel.org&gt;
</content>
</entry>
<entry>
<title>ima: add crypto agility support for template-hash algorithm</title>
<updated>2024-04-12T13:59:04+00:00</updated>
<author>
<name>Enrico Bravi</name>
<email>enrico.bravi@polito.it</email>
</author>
<published>2024-04-12T09:09:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9fa8e76250082a45d0d3dad525419ab98bd01658'/>
<id>urn:sha1:9fa8e76250082a45d0d3dad525419ab98bd01658</id>
<content type='text'>
The template hash showed by the ascii_runtime_measurements and
binary_runtime_measurements is the one calculated using sha1 and there is
no possibility to change this value, despite the fact that the template
hash is calculated using the hash algorithms corresponding to all the PCR
banks configured in the TPM.

Add the support to retrieve the ima log with the template data hash
calculated with a specific hash algorithm.
Add a new file in the securityfs ima directory for each hash algo
configured in a PCR bank of the TPM. Each new file has the name with
the following structure:

        {binary, ascii}_runtime_measurements_&lt;hash_algo_name&gt;

Legacy files are kept, to avoid breaking existing applications, but as
symbolic links which point to {binary, ascii}_runtime_measurements_sha1
files. These two files are created even if a TPM chip is not detected or
the sha1 bank is not configured in the TPM.

As example, in the case a TPM chip is present and sha256 is the only
configured PCR bank, the listing of the securityfs ima directory is the
following:

lr--r--r-- [...] ascii_runtime_measurements -&gt; ascii_runtime_measurements_sha1
-r--r----- [...] ascii_runtime_measurements_sha1
-r--r----- [...] ascii_runtime_measurements_sha256
lr--r--r-- [...] binary_runtime_measurements -&gt; binary_runtime_measurements_sha1
-r--r----- [...] binary_runtime_measurements_sha1
-r--r----- [...] binary_runtime_measurements_sha256
--w------- [...] policy
-r--r----- [...] runtime_measurements_count
-r--r----- [...] violations

Signed-off-by: Enrico Bravi &lt;enrico.bravi@polito.it&gt;
Signed-off-by: Silvia Sisinni &lt;silvia.sisinni@polito.it&gt;
Reviewed-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>mm, treewide: rename MAX_ORDER to MAX_PAGE_ORDER</title>
<updated>2024-01-08T23:27:15+00:00</updated>
<author>
<name>Kirill A. Shutemov</name>
<email>kirill.shutemov@linux.intel.com</email>
</author>
<published>2023-12-28T14:47:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5e0a760b44417f7cadd79de2204d6247109558a0'/>
<id>urn:sha1:5e0a760b44417f7cadd79de2204d6247109558a0</id>
<content type='text'>
commit 23baf831a32c ("mm, treewide: redefine MAX_ORDER sanely") has
changed the definition of MAX_ORDER to be inclusive.  This has caused
issues with code that was not yet upstream and depended on the previous
definition.

To draw attention to the altered meaning of the define, rename MAX_ORDER
to MAX_PAGE_ORDER.

Link: https://lkml.kernel.org/r/20231228144704.14033-2-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>mm, treewide: redefine MAX_ORDER sanely</title>
<updated>2023-04-06T02:42:46+00:00</updated>
<author>
<name>Kirill A. Shutemov</name>
<email>kirill.shutemov@linux.intel.com</email>
</author>
<published>2023-03-15T11:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=23baf831a32c04f9a968812511540b1b3e648bf5'/>
<id>urn:sha1:23baf831a32c04f9a968812511540b1b3e648bf5</id>
<content type='text'>
MAX_ORDER currently defined as number of orders page allocator supports:
user can ask buddy allocator for page order between 0 and MAX_ORDER-1.

This definition is counter-intuitive and lead to number of bugs all over
the kernel.

Change the definition of MAX_ORDER to be inclusive: the range of orders
user can ask from buddy allocator is 0..MAX_ORDER now.

[kirill@shutemov.name: fix min() warning]
  Link: https://lkml.kernel.org/r/20230315153800.32wib3n5rickolvh@box
[akpm@linux-foundation.org: fix another min_t warning]
[kirill@shutemov.name: fixups per Zi Yan]
  Link: https://lkml.kernel.org/r/20230316232144.b7ic4cif4kjiabws@box.shutemov.name
[akpm@linux-foundation.org: fix underlining in docs]
  Link: https://lore.kernel.org/oe-kbuild-all/202303191025.VRCTk6mP-lkp@intel.com/
Link: https://lkml.kernel.org/r/20230315113133.11326-11-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Reviewed-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;	[powerpc]
Cc: "Kirill A. Shutemov" &lt;kirill@shutemov.name&gt;
Cc: Zi Yan &lt;ziy@nvidia.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>ima: Fix potential memory leak in ima_init_crypto()</title>
<updated>2022-07-13T14:13:58+00:00</updated>
<author>
<name>Jianglei Nie</name>
<email>niejianglei2021@163.com</email>
</author>
<published>2022-07-12T01:10:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=067d2521874135267e681c19d42761c601d503d6'/>
<id>urn:sha1:067d2521874135267e681c19d42761c601d503d6</id>
<content type='text'>
On failure to allocate the SHA1 tfm, IMA fails to initialize and exits
without freeing the ima_algo_array. Add the missing kfree() for
ima_algo_array to avoid the potential memory leak.

Signed-off-by: Jianglei Nie &lt;niejianglei2021@163.com&gt;
Fixes: 6d94809af6b0 ("ima: Allocate and initialize tfm for each PCR bank")
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>ima/evm: Fix type mismatch</title>
<updated>2021-06-08T20:29:10+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2021-06-08T12:31:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6b26285f44c9306747c609cb304f787f1933594c'/>
<id>urn:sha1:6b26285f44c9306747c609cb304f787f1933594c</id>
<content type='text'>
The endianness of a variable written to the measurement list cannot be
determined at compile time, as it depends on the value of the
ima_canonical_fmt global variable (set through a kernel option with the
same name if the machine is big endian).

If ima_canonical_fmt is false, the endianness of a variable is the same as
the machine; if ima_canonical_fmt is true, the endianness is little endian.
The warning arises due to this type of instruction:

var = cpu_to_leXX(var)

which tries to assign a value in little endian to a variable with native
endianness (little or big endian).

Given that the variables set with this instruction are not used in any
operation but just written to a buffer, it is safe to force the type of the
value being set to be the same of the type of the variable with:

var = (__force &lt;var type&gt;)cpu_to_leXX(var)

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
</entry>
</feed>
