<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/drivers/crypto, branch linux-6.1.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-6.1.y</id>
<link rel='self' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-6.1.y'/>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2026-09-14T11:25:37+00:00</updated>
<entry>
<title>crypto: hisilicon/sec2 - fix CCM algorithm long packet failure</title>
<updated>2026-09-14T11:25:37+00:00</updated>
<author>
<name>Zhushuai Yin</name>
<email>yinzhushuai@huawei.com</email>
</author>
<published>2026-08-04T02:22:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5fec1784c74aaf85670eac7a9f69845274369f00'/>
<id>urn:sha1:5fec1784c74aaf85670eac7a9f69845274369f00</id>
<content type='text'>
[ Upstream commit b82f60be50c87b3d75e207852c5ca74fa18f66cf ]

In the CCM B0 block the message-length field Q spans L bytes, where
L (cl in the driver) is derived from the cipher IV flags byte as
c_ivin[0] + 1. set_aead_auth_iv() hardcoded writing only the last 2
bytes of a_ivin with cryptlen, implicitly assuming cl = 2.

When cl = 3 (a shorter nonce yielding a 3-byte length field) and the
packet is longer than 65535 bytes, cryptlen no longer fits in 2 bytes.
The dropped high byte made the auth IV built by the driver differ from
the one consumed by the hardware, so the software/hardware comparison
failed and the CCM request errored out.

Write the last cl bytes of a_ivin in a loop driven by the IV's CL
value, so the length-field width always matches the algorithm
configuration instead of assuming a fixed 2-byte field.

Fixes: c16a70c1f253 ("crypto: hisilicon/sec - add new algorithm mode for AEAD")
Signed-off-by: Zhushuai Yin &lt;yinzhushuai@huawei.com&gt;
Signed-off-by: Chenghai Huang &lt;huangchenghai2@huawei.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: keembay - publish OF module alias for OCS AES/SM4</title>
<updated>2026-09-14T11:24:57+00:00</updated>
<author>
<name>Can Peng</name>
<email>pengcan@kylinos.cn</email>
</author>
<published>2026-07-14T13:14:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=2cf48bfb7a39207d16ac44bf7056e15e430047d3'/>
<id>urn:sha1:2cf48bfb7a39207d16ac44bf7056e15e430047d3</id>
<content type='text'>
[ Upstream commit 0a94091e29f914e4f233a208599ca4055882c01b ]

The Keem Bay OCS AES/SM4 driver has an OF match table wired to
.of_match_table, but does not export the table with MODULE_DEVICE_TABLE().

Although the match table lives in keembay-ocs-aes-core.o, that object is
part of the composite keembay-ocs-aes module.  Add the missing
MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module alias
information for OF based module autoloading.

This is a source-level fix.  It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by the
platform driver, and the missing module alias publication.

Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4")
Signed-off-by: Can Peng &lt;pengcan@kylinos.cn&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: keembay - Initialize completion before requesting IRQ</title>
<updated>2026-09-14T11:24:57+00:00</updated>
<author>
<name>Linmao Li</name>
<email>lilinmao@kylinos.cn</email>
</author>
<published>2026-07-14T03:30:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=4ce407055ae9d37f46a3c6f05eb27198b354d287'/>
<id>urn:sha1:4ce407055ae9d37f46a3c6f05eb27198b354d287</id>
<content type='text'>
[ Upstream commit fce20289dd622cc7ab78d72c8a979a9f8b7cb10e ]

kmb_ocs_aes_probe() requests the device IRQ before initializing
irq_completion. Once the handler is registered it can run immediately,
and ocs_aes_irq_handler() unconditionally calls complete(). An
interrupt in this window would therefore use an uninitialized
completion.

Initialize the completion before requesting the IRQ, as the sibling
OCS HCU and ECC drivers already do.

Fixes: 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4")
Signed-off-by: Linmao Li &lt;lilinmao@kylinos.cn&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: sl3516 - drop invalid sg_dma_len checks before DMA mapping</title>
<updated>2026-09-14T11:24:45+00:00</updated>
<author>
<name>Thorsten Blum</name>
<email>thorsten.blum@linux.dev</email>
</author>
<published>2026-07-10T07:42:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=edb5089a27d28f62b54a72c47cad639b20696a96'/>
<id>urn:sha1:edb5089a27d28f62b54a72c47cad639b20696a96</id>
<content type='text'>
[ Upstream commit 3ae59a2eba64b3648f069aa52eeaaeefdfe4bb2f ]

sg_dma_len() is only valid after mapping the scatterlist with
dma_map_sg(). However, sl3516_ce_need_fallback() checks it before the
source and destination scatterlists are mapped. Thus, a stale DMA length
that is not a multiple of 16 could incorrectly force a software fallback
when CONFIG_NEED_SG_DMA_LENGTH=y.

Remove the invalid checks; the existing scatterlist length checks are
sufficient.

Fixes: 46c5338db7bd ("crypto: sl3516 - Add sl3516 crypto engine")
Signed-off-by: Thorsten Blum &lt;thorsten.blum@linux.dev&gt;
Acked-by: Linus Walleij &lt;linusw@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: sa2ul - stop probe if context pool creation fails</title>
<updated>2026-09-14T11:24:38+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-06-16T00:46:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=9a692a6a2b47328a36c8d80c7fbf81da16b6d6b1'/>
<id>urn:sha1:9a692a6a2b47328a36c8d80c7fbf81da16b6d6b1</id>
<content type='text'>
[ Upstream commit d03f980a25853f6a380895119a572a3bb1194e8d ]

sa_ul_probe() calls sa_init_mem() to create the DMA pool used for
security context buffers, but ignores its return value. If pool creation
fails, probe still continues with DMA setup, algorithm registration and
child population even though later request setup depends on that pool.

Stop probing when sa_init_mem() fails, and route that failure to the PM
cleanup path without attempting to destroy an uncreated DMA pool.

Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver")
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: atmel-sha204a - fix heap info leak on I2C transfer failure</title>
<updated>2026-09-14T11:24:38+00:00</updated>
<author>
<name>Lothar Rubusch</name>
<email>l.rubusch@gmail.com</email>
</author>
<published>2026-06-13T20:20:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=bcac9052e19490231ff6e0678a06bd2fcf8db3af'/>
<id>urn:sha1:bcac9052e19490231ff6e0678a06bd2fcf8db3af</id>
<content type='text'>
[ Upstream commit 72bbf11ba14bd7d5fbf31a1ec42fff608b657f74 ]

The nonblocking RNG path allocates a work_data structure to track the
state of an in-flight asynchronous I2C request. This pointer is stored
in rng-&gt;priv and later consumed by the read path once the transaction
completes.

If the underlying I2C transfer fails, the completion callback is invoked
with a non-zero status. In this case, the allocated work_data is not
usable for producing RNG output and must not remain associated with the
hwrng state.

Previously, the failure path only logged a warning but left the pointer
state uncleared, which can result in subsequent read attempts observing
stale state and interpreting it as valid completion data.

Fix this by freeing the pending work_data. The I2C transaction reports
an error. This ensures that failed requests do not leave residual state
behind that could be interpreted as valid RNG data on later reads.
Clearing rng-&gt;priv is done at the subsequent call to nonblocking read.

Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
Signed-off-by: Lothar Rubusch &lt;l.rubusch@gmail.com&gt;
Assisted-by: Gemini:1.5 Pro [google]
Reviewed-by: Thorsten Blum &lt;thorsten.blum@linux.dev&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: atmel-ecc - reject hardware ECDH without a public key</title>
<updated>2026-09-14T11:24:38+00:00</updated>
<author>
<name>Thorsten Blum</name>
<email>thorsten.blum@linux.dev</email>
</author>
<published>2026-06-11T21:36:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=3ea8b780d68f02fe235c5051ce8ac4b4940b9259'/>
<id>urn:sha1:3ea8b780d68f02fe235c5051ce8ac4b4940b9259</id>
<content type='text'>
[ Upstream commit f240f9b588f4e2de89822adebf560a96b5d263ed ]

The hardware ECDH path in atmel_ecdh_compute_shared_secret() uses the
private key stored in the device. However, the public key is cached only
after atmel_ecdh_set_secret() successfully generated that private key
for the current tfm.

atmel_ecdh_generate_public_key() already rejects requests when no public
key is cached. Add the same check to atmel_ecdh_compute_shared_secret()
to prevent the device from using a private key that was not generated
for the current tfm.

Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Signed-off-by: Thorsten Blum &lt;thorsten.blum@linux.dev&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: atmel-ecc - clean up and improve ECDH comments</title>
<updated>2026-09-14T11:24:37+00:00</updated>
<author>
<name>Thorsten Blum</name>
<email>thorsten.blum@linux.dev</email>
</author>
<published>2026-06-09T10:05:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=cf1a58f1521b98d19d7a0a15d498b8c79d0efccd'/>
<id>urn:sha1:cf1a58f1521b98d19d7a0a15d498b8c79d0efccd</id>
<content type='text'>
[ Upstream commit 3e84fb698abada239d3e35ed3d52a24dbfda5f6a ]

Improve the kerneldoc for struct atmel_ecdh_ctx by removing the stale
"unsupported curves" wording, since the device only supports a single
curve (P-256), and move the set_secret() constraint to the description.

In atmel_ecdh_set_secret(), clarify that the device generates the
private key, and drop the redundant "only supports NIST P256" comment.

In atmel_ecdh_done() and atmel_ecdh_generate_public_key(), clarify the
truncation comments. Also note that a P-256 public key consists of two
32-byte coordinates in atmel_ecdh_compute_shared_secret(), and remove
the unnecessary fall-through comment and other redundant comments.

Signed-off-by: Thorsten Blum &lt;thorsten.blum@linux.dev&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: f240f9b588f4 ("crypto: atmel-ecc - reject hardware ECDH without a public key")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: atmel-ecc - replace min_t with min</title>
<updated>2026-09-14T11:24:37+00:00</updated>
<author>
<name>Thorsten Blum</name>
<email>thorsten.blum@linux.dev</email>
</author>
<published>2026-05-07T13:55:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=e1b6427161cf75c2b3a4d366e2fb8e5f3e52d8b7'/>
<id>urn:sha1:e1b6427161cf75c2b3a4d366e2fb8e5f3e52d8b7</id>
<content type='text'>
[ Upstream commit 5b085b2a038a1458f9398cb3b3b03cba6e38e1e0 ]

Use the simpler min() macro since the values are all unsigned and
compatible.

Signed-off-by: Thorsten Blum &lt;thorsten.blum@linux.dev&gt;
Reviewed-by: David Laight &lt;david.laght.linux@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Stable-dep-of: f240f9b588f4 ("crypto: atmel-ecc - reject hardware ECDH without a public key")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - clear AES key schedule from stack</title>
<updated>2026-09-14T11:24:37+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2026-06-08T15:04:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.landau.one/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=fb1194b78a163cc56bb9480c707fc34b53522359'/>
<id>urn:sha1:fb1194b78a163cc56bb9480c707fc34b53522359</id>
<content type='text'>
[ Upstream commit d41a9fcfb7f9ee36e4a4aaf5e7996bca6be1e7a9 ]

qat_alg_xts_reverse_key() expands the forward XTS AES key on the stack.
That schedule contains key material and can remain in the stack frame.

Clear the temporary crypto_aes_ctx with memzero_explicit() after the copy.

Fixes: 5106dfeaeabe ("crypto: qat - add AES-XTS support for QAT GEN4 devices")
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Ahsan Atta &lt;ahsan.atta@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
