laptop-kernel/lib/crypto, branch master

lib/crypto: tests: Add Poly1305 split-update carry regression test

2026-10-09T17:21:07Z

Add a test case which reproduces the bug fixed by commit 24f07e8c07a0 ("lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state"). It is written in a fairly general way, such that it should also be able to reproduce similar bugs in other implementations. Update the comment on test_poly1305_allones_keys_and_message() to more accurately describe what it does and differentiate it from the new test. Reviewed-by: Jason A. Donenfeld Link: https://patch.msgid.link/20261009125354.315476-3-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: arm64: Fix lost Poly1305 carry when resuming NEON state

2026-10-09T17:20:29Z

When poly1305_blocks_neon() resumes from a base 2^26 accumulator and the next update contains an odd number of full 16-byte blocks, it processes one leading block through poly1305_mult() so that the remaining NEON work has an even block count. That requires converting the accumulator to the base 2^64 form used by poly1305_mult(). The final ADC of that conversion stores the carry into d2, but the following accumulation and poly1305_mult() use h2. If the conversion carries across bit 128, the carry is dropped and the emitted tag is wrong. This was introduced by Cryptogams commit 03dc4adf91c8 ("arm/poly1305-armv*.pl: optimize branches."), which removed the reduction that consumed d2 shortly before Linux imported the code. OpenSSL's copy did not take that change. The carry is possible because the NEON code stores the accumulator [h0, h1, h2, h3, h4] in a lazily reduced, redundant base 2^26 form: its final carry chain leaves h0, h2, h3 < 2^26, but h1 and h4 may slightly exceed 2^26 - 1. For example, the reachable state h0 = 4 h1 = 2^26 h2 = 2^26 - 1 h3 = 2^26 - 1 h4 = 2^24 - 1 represents 4 + 2^26*2^26 + (2^26-1)*2^52 + (2^26-1)*2^78 + (2^24-1)*2^104 = 2^128 + 4, despite the bit representing the 2^128 term (bit 24 of h4) not being set; the extra comes from the h1 limb being above the normal base 2^26 range. When this value is converted into the non-redundant base 2^64 form, a carry into the new 2^128 bit (in bit 0 of h2) is necessary to preserve the value. Given the above bounds, a carry into bit 128 happens exactly when h1 >= 2^26, h2 = h3 = 2^26 - 1, and h4 mod 2^24 = 2^24 - 1. Store the carry into h2, matching the other base 2^26 to base 2^64 conversions in poly1305_blocks() and poly1305_emit(). This bug causes an incorrect tag to be emitted. However, this is unlikely to happen in practice where Poly1305 is used with a random key, since the random key tends to distribute the accumulator values throughout their valid range. There isn't an obvious way for an attacker without knowledge of the r_key to cause [h0, h1, h2, h3, h4] to land on the precise values where this bug occurs. [EB: Rewrote the commit message to more clearly describe the bug and its impact, and simplified explanation about why there's a carry bit.] Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Cc: stable@vger.kernel.org Assisted-by: LLM Reviewed-by: Jason A. Donenfeld Signed-off-by: Jérémy Jean Link: https://patch.msgid.link/20261009125354.315476-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: poly1305: Use memzero_explicit() in poly1305_final()

2026-10-09T17:20:29Z

Use memzero_explicit() instead of a plain struct assignment to guarantee zeroization of the 'struct poly1305_desc_ctx'. Note that dead store elimination was only theoretically possible with link-time optimization here. But it's still worth fixing. Fixes: a1d93064094c ("crypto: poly1305 - expose init/update/final library interface") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/bug/linux-c3a6bd76-f6ab-4203-892a-cd06f7aa0c34 Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20261006083432.16328-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes-cmac: Use __cleanup() instead of memzero_explicit()

2026-08-11T03:17:56Z

By using __cleanup(aes_cmac_zeroize_key) for clearing the key data, we can save one line of code here. Signed-off-by: Thomas Huth Link: https://patch.msgid.link/20260807125845.1477067-6-thuth@redhat.com Signed-off-by: Eric Biggers

lib/crypto: tests: Add KUnit test suite for AES-GCM

2026-08-11T03:17:56Z

Add a KUnit test suite for the AES-GCM library API. It consists of: - All the shared test cases from aead-test-template.h. These include extensive consistency tests, a "Monte-Carlo test", and a benchmark. - Tests against hardcoded AES-GCM test vectors from external sources. Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260802233005.161467-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Add KUnit test suite for AES-CCM

2026-08-11T03:17:56Z

Add a KUnit test suite for the AES-CCM library API. It consists of: - All the shared test cases from aead-test-template.h. These include extensive consistency tests, a "Monte-Carlo test", and a benchmark. - Tests against hardcoded AES-CCM test vectors from external sources. - Tests for CCM-specific message length validation. To generate the expected aes_ccm_monte_carlo_checksum[] value, add a script gen-aead-testvecs.py which computes it using python-cryptography. Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260802233005.161467-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Add aead-test-template.h

2026-08-11T03:17:56Z

Add aead-test-template.h which contains shared test logic for AEAD algorithms. It's similar to the existing hash-test-template.h, which contains shared test logic for hash algorithms. The initial use cases for this will be AES-CCM and AES-GCM. It may be used by the existing ChaCha20Poly1305 test suite in the future as well, though the ChaCha20Poly1305 API currently lacks some of the functionality that the "template" expects to be present. Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260802233005.161467-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Use per-test-case buffers in hash tests

2026-08-11T03:17:56Z

Make the test cases more self-contained by replacing the test suite scoped guarded buffer ('test_buf') with buffers allocated by each test case using the helper functions in test-utils.h. Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260802233005.161467-3-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: tests: Create test-utils.h

2026-08-11T03:17:56Z

Move hash-test-template's test RNG code and the buffer allocation code from various test suites into a header test-utils.h. This allows them to be shared by other test suites. Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260802233005.161467-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add FIPS self-tests for GCM and CCM

2026-08-11T03:17:56Z

Upcoming changes will wire up architecture-optimized implementations of GCM and CCM. FIPS labs can consider such designs to meet the threshold for separate self-tests to be needed. Therefore, add FIPS self-tests for encryption and decryption in these modes. Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260802222408.91757-4-ebiggers@kernel.org Signed-off-by: Eric Biggers