<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/crypto/caam, branch v6.19.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-11T12:29:23+00:00</updated>
<entry>
<title>crypto: caam - fix overflow on long hmac keys</title>
<updated>2026-04-11T12:29:23+00:00</updated>
<author>
<name>Horia Geantă</name>
<email>horia.geanta@nxp.com</email>
</author>
<published>2026-03-17T10:25:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cebc5ebd958346195b77f42d0cd5141b4e448fae'/>
<id>urn:sha1:cebc5ebd958346195b77f42d0cd5141b4e448fae</id>
<content type='text'>
[ Upstream commit 80688afb9c35b3934ce2d6be9973758915e2e0ef ]

When a key longer than block size is supplied, it is copied and then
hashed into the real key.  The memory allocated for the copy needs to
be rounded to DMA cache alignment, as otherwise the hashed key may
corrupt neighbouring memory.

The copying is performed using kmemdup, however this leads to an overflow:
reading more bytes (aligned_len - keylen) from the keylen source buffer.
Fix this by replacing kmemdup with kmalloc, followed by memcpy.

Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding")
Signed-off-by: Horia Geantă &lt;horia.geanta@nxp.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: caam - fix DMA corruption on long hmac keys</title>
<updated>2026-04-11T12:29:23+00:00</updated>
<author>
<name>Horia Geantă</name>
<email>horia.geanta@nxp.com</email>
</author>
<published>2026-03-17T10:25:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f2af8be110bde26b3e3354efdfdda97f426306a4'/>
<id>urn:sha1:f2af8be110bde26b3e3354efdfdda97f426306a4</id>
<content type='text'>
[ Upstream commit 5ddfdcbe10dc5f97afc4e46ca22be2be717e8caf ]

When a key longer than block size is supplied, it is copied and then
hashed into the real key.  The memory allocated for the copy needs to
be rounded to DMA cache alignment, as otherwise the hashed key may
corrupt neighbouring memory.

The rounding was performed, but never actually used for the allocation.
Fix this by replacing kmemdup with kmalloc for a larger buffer,
followed by memcpy.

Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding")
Reported-by: Paul Bunyan &lt;pbunyan@redhat.com&gt;
Signed-off-by: Horia Geantă &lt;horia.geanta@nxp.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: caam - fix netdev memory leak in dpaa2_caam_probe</title>
<updated>2026-02-26T23:00:48+00:00</updated>
<author>
<name>Jianpeng Chang</name>
<email>jianpeng.chang.cn@windriver.com</email>
</author>
<published>2026-01-20T01:55:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e144cce29851610ce9c6eda405ce21118779aa51'/>
<id>urn:sha1:e144cce29851610ce9c6eda405ce21118779aa51</id>
<content type='text'>
[ Upstream commit 7d43252b3060b0ba4a192dce5dba85a3f39ffe39 ]

When commit 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in
dpaa2") converted embedded net_device to dynamically allocated pointers,
it added cleanup in dpaa2_dpseci_disable() but missed adding cleanup in
dpaa2_dpseci_free() for error paths.

This causes memory leaks when dpaa2_dpseci_dpio_setup() fails during probe
due to DPIO devices not being ready yet. The kernel's deferred probe
mechanism handles the retry successfully, but the netdevs allocated during
the failed probe attempt are never freed, resulting in kmemleak reports
showing multiple leaked netdev-related allocations all traced back to
dpaa2_caam_probe().

Fix this by preserving the CPU mask of allocated netdevs during setup and
using it for cleanup in dpaa2_dpseci_free(). This approach ensures that
only the CPUs that actually had netdevs allocated will be cleaned up,
avoiding potential issues with CPU hotplug scenarios.

Fixes: 0e1a4d427f58 ("crypto: caam: Unembed net_dev structure in dpaa2")
Signed-off-by: Jianpeng Chang &lt;jianpeng.chang.cn@windriver.com&gt;
Reviewed-by: Breno Leitao &lt;leitao@debian.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: caam - Add support of paes algorithm</title>
<updated>2025-10-20T04:10:28+00:00</updated>
<author>
<name>Meenakshi Aggarwal</name>
<email>meenakshi.aggarwal@nxp.com</email>
</author>
<published>2025-10-06T07:17:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=66b9a095f7f9e1031e5333661be513e89e40ee08'/>
<id>urn:sha1:66b9a095f7f9e1031e5333661be513e89e40ee08</id>
<content type='text'>
PAES algorithm uses protected key for encryption/decryption operations.

Signed-off-by: Gaurav Jain &lt;gaurav.jain@nxp.com&gt;
Signed-off-by: Meenakshi Aggarwal &lt;meenakshi.aggarwal@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>KEYS: trusted: caam based protected key</title>
<updated>2025-10-20T04:10:28+00:00</updated>
<author>
<name>Meenakshi Aggarwal</name>
<email>meenakshi.aggarwal@nxp.com</email>
</author>
<published>2025-10-06T07:17:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a703a4c2a3280835003d4d0eb8845bac0f1a6ef1'/>
<id>urn:sha1:a703a4c2a3280835003d4d0eb8845bac0f1a6ef1</id>
<content type='text'>
- CAAM supports two types of protected keys:
  -- Plain key encrypted with ECB
  -- Plain key encrypted with CCM
  Due to robustness, default encryption used for protected key is CCM.

- Generate protected key blob and add it to trusted key payload.
  This is done as part of sealing operation, which is triggered
  when below two operations are requested:
  -- new key generation
  -- load key,

Signed-off-by: Pankaj Gupta &lt;pankaj.gupta@nxp.com&gt;
Signed-off-by: Meenakshi Aggarwal &lt;meenakshi.aggarwal@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: caam - Add check for kcalloc() in test_len()</title>
<updated>2025-10-17T08:03:57+00:00</updated>
<author>
<name>Guangshuo Li</name>
<email>lgs201920130244@gmail.com</email>
</author>
<published>2025-09-23T12:44:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cf6e0b69b0d90ab042163e5bbddda0dfcf8b6a7'/>
<id>urn:sha1:7cf6e0b69b0d90ab042163e5bbddda0dfcf8b6a7</id>
<content type='text'>
As kcalloc() may fail, check its return value to avoid a NULL pointer
dereference when passing the buffer to rng-&gt;read(). On allocation
failure, log the error and return since test_len() returns void.

Fixes: 2be0d806e25e ("crypto: caam - add a test for the RNG")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li &lt;lgs201920130244@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: caam - double the entropy delay interval for retry</title>
<updated>2025-09-13T04:11:06+00:00</updated>
<author>
<name>Gaurav Jain</name>
<email>gaurav.jain@nxp.com</email>
</author>
<published>2025-09-05T10:11:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9048beca9c5614d486e2b492c0a7867164bf56a8'/>
<id>urn:sha1:9048beca9c5614d486e2b492c0a7867164bf56a8</id>
<content type='text'>
during entropy evaluation, if the generated samples fail
any statistical test, then, all of the bits will be discarded,
and a second set of samples will be generated and tested.

the entropy delay interval should be doubled before performing the
retry.

also, ctrlpriv-&gt;rng4_sh_init and inst_handles both reads RNG DRNG
status register, but only inst_handles is updated before every retry.
so only check inst_handles and removing ctrlpriv-&gt;rng4_sh_init

Signed-off-by: Gaurav Jain &lt;gaurav.jain@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: caam - switch to use devm_kmemdup_array()</title>
<updated>2025-09-06T07:57:23+00:00</updated>
<author>
<name>Zhang Enpei</name>
<email>zhang.enpei@zte.com.cn</email>
</author>
<published>2025-08-27T07:52:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab315f7288b75c289cf4a81d18d6b21e13022364'/>
<id>urn:sha1:ab315f7288b75c289cf4a81d18d6b21e13022364</id>
<content type='text'>
Use devm_kmemdup_array() to avoid multiplication or possible overflows.

Signed-off-by: Zhang Enpei &lt;zhang.enpei@zte.com.cn&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: engine - remove request batching support</title>
<updated>2025-07-18T10:52:00+00:00</updated>
<author>
<name>Ovidiu Panait</name>
<email>ovidiu.panait.oss@gmail.com</email>
</author>
<published>2025-07-11T18:29:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c470ffa6f48619e8ea2442206b31b7965f8826a5'/>
<id>urn:sha1:c470ffa6f48619e8ea2442206b31b7965f8826a5</id>
<content type='text'>
Remove request batching support from crypto_engine, as there are no
drivers using this feature and it doesn't really work that well.

Instead of doing batching based on backlog, a more optimal approach
would be for the user to handle the batching (similar to how IPsec
can hook into GSO to get 64K of data each time or how block encryption
can use unit sizes much greater than 4K).

Suggested-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Ovidiu Panait &lt;ovidiu.panait.oss@gmail.com&gt;
Reviewed-by: Horia Geantă &lt;horia.geanta@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
<entry>
<title>crypto: caam - avoid option aliasing with the CONFIG_CAAM_QI build option</title>
<updated>2025-07-18T10:51:59+00:00</updated>
<author>
<name>Lukas Bulwahn</name>
<email>lukas.bulwahn@redhat.com</email>
</author>
<published>2025-07-01T11:20:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75e2d4b1eddcfafd3b3961490f7da0bae4ecb451'/>
<id>urn:sha1:75e2d4b1eddcfafd3b3961490f7da0bae4ecb451</id>
<content type='text'>
In the Makefile, the new build option CONFIG_CAAM_QI is defined conditioned
on the existence of the CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI, which is
properly defined in the Kconfig file. So, CONFIG_CAAM_QI is just a local
alias for CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI.

There is little benefit in the source code of having this slightly shorter
alias for this configuration, but it complicates further maintenance, as
searching for the impact of CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI
requires to grep once, and then identify the option introduced and continue
searching for that. Further, tools, such as cross referencers, and scripts
to check Kconfig definitions and their use simply do not handle this
situation. Given that this is the only incidence of such a config alias in
the whole kernel tree, just prefer to avoid this pattern of aliasing here.

Use CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI throughout the Freescale
CAAM-Multicore platform driver backend source code.

No functional change.

Signed-off-by: Lukas Bulwahn &lt;lukas.bulwahn@redhat.com&gt;
Reviewed-by: Horia Geantă &lt;horia.geanta@nxp.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
