* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Kamran Khan @ 2026-05-10 15:54 UTC (permalink / raw)
To: Jeff Barnes, Andy Lutomirski
Cc: Eric Biggers, linux-crypto@vger.kernel.org, Herbert Xu,
linux-doc@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Linus Torvalds
In-Reply-To: <14A441D8-5370-44BE-8732-99BF8107C3FD@getmailspring.com>
Hi,
AF_ALG is useful not just for hardware-offloading, but also for memory
isolation so that applications only get oracle access to the crypto keys
and a memory-safety vulnerability in user applications would not
immediately put the secret key material at risk.
I understand and appreciate the concern with complex attack surface and
the increased frequency of attacks in this area. But I fear that
completely removing AF_ALG increases the risk for userspace applications
relying on it for memory isolation.
What alternatives do userspace applications have on Linux for ensuring
crypto keys are not exposed in user memory? That is, FreeBSD and NetBSD
natively provide /dev/crypto; removing AF_ALG would kill the only
equivalent option on the Linux side for kernel-delegated cryptography.
Thanks,
Kamran.
On 5/6/26 7:42 AM, Jeff Barnes wrote:
> Hi,
>
> On May 5 2026, at 7:17 pm, Andy Lutomirski <luto@amacapital.net> wrote:
>
>>> On Apr 29, 2026, at 6:19 PM, Eric Biggers <ebiggers@kernel.org> wrote:
>>>
>>> AF_ALG is almost completely unnecessary, and it exposes a massive attack
>>> surface that hasn't been standing up to modern vulnerability discovery
>>> tools. The latest one even has its own website, providing a small
>>> Python script that reliably roots most Linux distros: https://copy.fail/
>>
>> How about adding a configuration option, defaulted on, that requires
>> capable(CAP_SYS_ADMIN) to create the socket (and maybe also to bind /
>> connect it). And a sysctl to allow the administrator to override this
>> in the unlikely event that it’s needed.
>>
>> IIRC cryptsetup used to and maybe even still does require these
>> sockets sometimes and this would let it keep working. And there's all
>> the FIPS stuff downthread.
>
> Apologize in advance for the long-winded answer.
>
> The "FIPS stuff" centers on using sha512hmac -> libkcapi -> AF_ALG for
> verifying integrity. The early‑boot sha512hmac check that some
> distributions use (typically from initramfs) sits at an awkward
> intersection of multiple standards, and it may help to clarify where it
> actually fits and where it doesn't.
>
> From a standards perspective, FIPS 140‑3 requires a cryptographic module
> to perform self‑integrity verification using an approved algorithm and
> to prevent the module from entering an operational state on failure. In
> the Linux kernel, the cryptographic module is the kernel crypto
> subsystem, and these requirements are met by the kernel’s internal
> power‑up self‑tests (KATs, etc.) on the crypto code and critical data as
> loaded into memory.
>
> FIPS 199 / SP 800‑53 (e.g., SI‑7) impose system‑level integrity
> requirements (for Moderate impact systems), i.e., that unauthorized
> modification of critical components is prevented or detected and that
> failures result in a protective action. These controls are explicitly
> technology‑agnostic and are not limited to cryptographic‑module self‑tests.
>
> The sha512hmac check is not the FIPS 140‑3 cryptographic‑module
> self‑integrity test. Instead, it has historically been used as a system
> integrity control that provides auditors with assurance that the kernel
> image containing the cryptographic module has not been modified prior to
> execution, and that a failure will halt the boot.
>
> Although FIPS 140‑3 does not mandate an HMAC over the kernel image, the
> early‑boot HMAC became an accepted evidence pattern for satisfying
> system‑integrity expectations (FIPS 199 / SI‑7) alongside a kernel
> crypto validation. This is why it is often perceived as “required” for
> FIPS submissions, even though it is not normatively required by
> FIPS 140‑3 itself.
>
> With the deprecation/removal of AF_ALG for this use case, there is no
> longer a supported way to perform an early‑boot, userspace‑driven HMAC
> using validated kernel crypto without introducing circular dependencies
> (e.g., relying on userspace crypto before crypto self‑tests complete).
> As a result, there is no drop‑in replacement for sha512hmac that
> preserves all of its historical properties.
>
> This is a new development that challenges a long‑standing assumption:
> that system‑integrity evidence and cryptographic‑module self‑integrity
> can be cleanly separated while still being demonstrated by a single
> early‑boot mechanism. That assumption no longer holds given proposed
> kernel interfaces.
>
> A more accurate decomposition (and one that aligns with the intent of
> the standards) is to separate integrity enforcement by system phase.
>
> 1. Secure Boot (or equivalent platform verification) ensures that a
> modified kernel image is not executed at all. This satisfies the
> requirement that critical components are not loaded in a modified state
> and that integrity failure results in a protective action (boot prevention).
>
> 2. IMA (with appraisal and enforcement) ensures that modified
> executables, modules, or firmware cannot be loaded or executed once the
> kernel is running.
>
> 3. Kernel crypto self‑tests continue to satisfy FIPS 140‑3
> self‑integrity requirements independently of the above.
>
> Taken together, Secure Boot + IMA provide continuous system‑integrity
> enforcement without re‑introducing early‑boot HMACs or AF_ALG
> dependencies, while keeping cryptographic‑module self‑integrity
> correctly scoped to the kernel crypto subsystem.
>
> The transition away from sha512hmac is therefore not a removal of
> integrity enforcement, but a shift from a single, early‑boot mechanism
> to a phased integrity model that better reflects the separation of
> concerns already present in the standards — even though this separation
> was previously masked by the hacky HMAC approach.
>
> This change will require updated documentation and auditor education,
> but it reflects the current technical reality and avoids perpetuating an
> interface that no longer has a sustainable implementation path.
>
>>
>>
>>>
>>> This isn't sustainable, especially as LLMs have accelerated the rate the
>>> vulnerabilities are coming in. The effort that is being put into this
>>> thing is vastly disproportional to the few programs that actually use
>>> it, and those programs would be better served by userspace code anyway.
>>>
>>> These issues have been noted in many mailing list discussions already.
>>> But until now they haven't been reflected in the documentation or
>>> kconfig menu itself, and the vulnerabilities are still coming in.
>>>
>>> Let's go ahead and document the deprecation.
>>>
>>> This isn't intended to change anything overnight. After all, most Linux
>>> distros won't be able to disable the kconfig options quite yet, mainly
>>> because of iwd. But this should create a bit more impetus for these
>>> userspace programs to be fixed, and the documentation update should also
>>> help prevent more users from appearing.
>>>
>>> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
>>> ---
>>>
>>> This patch is targeting crypto/master
>>>
>>> Documentation/crypto/userspace-if.rst | 82 ++++++++++++++++++++-------
>>> crypto/Kconfig | 69 ++++++++++++++++------
>>> 2 files changed, 113 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
>>> index 021759198fe7..c39f5c79a5b7 100644
>>> --- a/Documentation/crypto/userspace-if.rst
>>> +++ b/Documentation/crypto/userspace-if.rst
>>> @@ -2,30 +2,72 @@ User Space Interface
>>> ====================
>>>
>>> Introduction
>>> ------------
>>>
>>> -The concepts of the kernel crypto API visible to kernel space is fully
>>> -applicable to the user space interface as well. Therefore, the kernel
>>> -crypto API high level discussion for the in-kernel use cases applies
>>> -here as well.
>>> -
>>> -The major difference, however, is that user space can only act as a
>>> -consumer and never as a provider of a transformation or cipher
>>> -algorithm.
>>> -
>>> -The following covers the user space interface exported by the kernel
>>> -crypto API. A working example of this description is libkcapi that can
>>> -be obtained from [1]. That library can be used by user space
>>> -applications that require cryptographic services from the kernel.
>>> -
>>> -Some details of the in-kernel kernel crypto API aspects do not apply to
>>> -user space, however. This includes the difference between synchronous
>>> -and asynchronous invocations. The user space API call is fully
>>> -synchronous.
>>> -
>>> -[1] https://www.chronox.de/libkcapi/index.html
>>> +AF_ALG provides unprivileged userspace programs access to arbitrary hash,
>>> +symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode
>>> +code.
>>> +
>>> +AF_ALG is insecure and is deprecated. Originally added to the kernel
>>> in 2010,
>>> +most kernel developers now consider it to be a mistake.
>>> +
>>> +AF_ALG continues to be supported only for backwards compatibility.
>>> On systems
>>> +where no programs using AF_ALG remain, the support for it should be
>>> disabled by
>>> +disabling ``CONFIG_CRYPTO_USER_API_*``.
>>> +
>>> +Deprecation
>>> +-----------
>>> +
>>> +AF_ALG was originally intended to provide userspace programs access
>>> to crypto
>>> +accelerators that they wouldn't otherwise have access to.
>>> +
>>> +However, that capability turned out to not be useful on very many
>>> systems. More
>>> +significantly, the actual implementation exposes a vastly greater
>>> amount of
>>> +functionality than that. It actually provides access to all software algorithms.
>>> +
>>> +This includes arbitrary compositions of different algorithms created
>>> via a
>>> +complex template system, as well as algorithms that only make sense
>>> as internal
>>> +implementation details of other algorithms. It also includes full zero-copy
>>> +support, which is difficult for the kernel to implement securely.
>>> +
>>> +Ultimately, these algorithms are just math computations. They use
>>> the same
>>> +instructions that userspace programs already have access to, just
>>> accessed in a
>>> +much more convoluted and less efficient way.
>>> +
>>> +Indeed, userspace code is nearly always what is being used anyway.
>>> These same
>>> +algorithms are widely implemented in userspace crypto libraries.
>>> +
>>> +Meanwhile, AF_ALG hasn't been withstanding modern vulnerability
>>> discovery tools
>>> +such as syzbot and large language models. It receives a steady
>>> stream of CVEs.
>>> +Some of the examples include:
>>> +
>>> +- CVE-2026-31677
>>> +- CVE-2026-31431 (https://copy.fail)
>>> +- CVE-2025-38079
>>> +- CVE-2025-37808
>>> +- CVE-2024-26824
>>> +- CVE-2022-48781
>>> +- CVE-2019-8912
>>> +- CVE-2018-14619
>>> +- CVE-2017-18075
>>> +- CVE-2017-17806
>>> +- CVE-2017-17805
>>> +- CVE-2016-10147
>>> +- CVE-2015-8970
>>> +- CVE-2015-3331
>>> +- CVE-2014-9644
>>> +- CVE-2013-7421
>>> +- CVE-2011-4081
>>> +
>>> +It is recommended that, whenever possible, userspace programs be
>>> migrated to
>>> +userspace crypto code (which again, is what is normally used anyway) and
>>> +``CONFIG_CRYPTO_USER_API_*`` be disabled. On systems that use
>>> SELinux, SELinux
>>> +can also be used to restrict the use of AF_ALG to trusted programs.
>>> +
>>> +The remainder of this documentation provides the historical
>>> documentation for
>>> +the deprecated AF_ALG interface.
>>>
>>> User Space API General Remarks
>>> ------------------------------
>>>
>>> The kernel crypto API is accessible from user space. Currently, the
>>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>>> index 103d1f58cb7c..6cd1c478d4be 100644
>>> --- a/crypto/Kconfig
>>> +++ b/crypto/Kconfig
>>> @@ -1278,48 +1278,72 @@ config CRYPTO_DF80090A
>>> tristate
>>> select CRYPTO_AES
>>> select CRYPTO_CTR
>>>
>>> endmenu
>>> -menu "Userspace interface"
>>> +menu "Userspace interface (deprecated)"
>>>
>>> config CRYPTO_USER_API
>>> tristate
>>>
>>> config CRYPTO_USER_API_HASH
>>> - tristate "Hash algorithms"
>>> + tristate "Hash algorithms (deprecated)"
>>> depends on NET
>>> select CRYPTO_HASH
>>> select CRYPTO_USER_API
>>> help
>>> - Enable the userspace interface for hash algorithms.
>>> + Enable the AF_ALG userspace interface for hash algorithms. This
>>> + provides unprivileged userspace programs access to arbitrary hash
>>> + algorithms implemented in the kernel's privileged execution context.
>>>
>>> - See Documentation/crypto/userspace-if.rst and
>>> - https://www.chronox.de/libkcapi/html/index.html
>>> + This interface is deprecated and is supported only for backwards
>>> + compatibility. It regularly has vulnerabilities, and the capabilities
>>> + it provides are redundant with userspace crypto libraries.
>>> +
>>> + Enable this only if needed for support for a program that
>>> hasn't yet
>>> + been converted to userspace crypto, for example iwd.
>>> +
>>> + See also Documentation/crypto/userspace-if.rst
>>>
>>> config CRYPTO_USER_API_SKCIPHER
>>> - tristate "Symmetric key cipher algorithms"
>>> + tristate "Symmetric key cipher algorithms (deprecated)"
>>> depends on NET
>>> select CRYPTO_SKCIPHER
>>> select CRYPTO_USER_API
>>> help
>>> - Enable the userspace interface for symmetric key cipher algorithms.
>>> + Enable the AF_ALG userspace interface for symmetric key algorithms.
>>> + This provides unprivileged userspace programs access to arbitrary
>>> + symmetric key algorithms implemented in the kernel's privileged
>>> + execution context.
>>> +
>>> + This interface is deprecated and is supported only for backwards
>>> + compatibility. It regularly has vulnerabilities, and the capabilities
>>> + it provides are redundant with userspace crypto libraries.
>>> +
>>> + Enable this only if needed for support for a program that
>>> hasn't yet
>>> + been converted to userspace crypto, for example iwd, or cryptsetup
>>> + with certain algorithms.
>>>
>>> - See Documentation/crypto/userspace-if.rst and
>>> - https://www.chronox.de/libkcapi/html/index.html
>>> + See also Documentation/crypto/userspace-if.rst
>>>
>>> config CRYPTO_USER_API_RNG
>>> - tristate "RNG (random number generator) algorithms"
>>> + tristate "Random number generation algorithms (deprecated)"
>>> depends on NET
>>> select CRYPTO_RNG
>>> select CRYPTO_USER_API
>>> help
>>> - Enable the userspace interface for RNG (random number generator)
>>> - algorithms.
>>> + Enable the AF_ALG userspace interface for random number generation
>>> + (RNG) algorithms. This provides unprivileged userspace programs
>>> + access to arbitrary RNG algorithms implemented in the kernel's
>>> + privileged execution context.
>>>
>>> - See Documentation/crypto/userspace-if.rst and
>>> - https://www.chronox.de/libkcapi/html/index.html
>>> + This interface is deprecated and is supported only for backwards
>>> + compatibility. It regularly has vulnerabilities, and the capabilities
>>> + it provides are redundant with userspace crypto libraries as
>>> well as
>>> + the normal kernel RNG (e.g., /dev/urandom and getrandom(2)).
>>> +
>>> + See also Documentation/crypto/userspace-if.rst
>>>
>>> config CRYPTO_USER_API_RNG_CAVP
>>> bool "Enable CAVP testing of DRBG"
>>> depends on CRYPTO_USER_API_RNG && CRYPTO_DRBG
>>> help
>>> @@ -1330,20 +1354,29 @@ config CRYPTO_USER_API_RNG_CAVP
>>>
>>> This should only be enabled for CAVP testing. You should say
>>> no unless you know what this is.
>>>
>>> config CRYPTO_USER_API_AEAD
>>> - tristate "AEAD cipher algorithms"
>>> + tristate "AEAD cipher algorithms (deprecated)"
>>> depends on NET
>>> select CRYPTO_AEAD
>>> select CRYPTO_SKCIPHER
>>> select CRYPTO_USER_API
>>> help
>>> - Enable the userspace interface for AEAD cipher algorithms.
>>> + Enable the AF_ALG userspace interface for authenticated encryption
>>> + with associated data (AEAD) algorithms. This provides unprivileged
>>> + userspace programs access to arbitrary AEAD algorithms
>>> implemented in
>>> + the kernel's privileged execution context.
>>> +
>>> + This interface is deprecated and is supported only for backwards
>>> + compatibility. It regularly has vulnerabilities, and the capabilities
>>> + it provides are redundant with userspace crypto libraries.
>>> +
>>> + Enable this only if needed for support for a program that
>>> hasn't yet
>>> + been converted to userspace crypto, for example iwd.
>>>
>>> - See Documentation/crypto/userspace-if.rst and
>>> - https://www.chronox.de/libkcapi/html/index.html
>>> + See also Documentation/crypto/userspace-if.rst
>>>
>>> config CRYPTO_USER_API_ENABLE_OBSOLETE
>>> bool "Obsolete cryptographic algorithms"
>>> depends on CRYPTO_USER_API
>>> default y
>>>
>>> base-commit: 57b8e2d666a31fa201432d58f5fe3469a0dd83ba
>>> --
>>> 2.54.0
>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix Use-After-Free in adf_ctl_ioctl_dev_start()
From: kernel test robot @ 2026-05-10 14:16 UTC (permalink / raw)
To: w15303746062, giovanni.cabiddu, herbert, davem
Cc: oe-kbuild-all, thorsten.blum, kees, qat-linux, linux-crypto,
linux-kernel, Mingyu Wang
In-Reply-To: <20260508023542.256299-1-w15303746062@163.com>
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on herbert-cryptodev-2.6/master]
[also build test ERROR on herbert-crypto-2.6/master linus/master v7.1-rc2 next-20260508]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/w15303746062-163-com/crypto-qat-fix-Use-After-Free-in-adf_ctl_ioctl_dev_start/20260510-110441
base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link: https://lore.kernel.org/r/20260508023542.256299-1-w15303746062%40163.com
patch subject: [PATCH] crypto: qat - fix Use-After-Free in adf_ctl_ioctl_dev_start()
config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20260510/202605102206.HtfQ4iA9-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260510/202605102206.HtfQ4iA9-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605102206.HtfQ4iA9-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c: In function 'adf_ctl_ioctl_dev_stop':
>> drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:286:13: error: 'accel_dev' undeclared (first use in this function); did you mean 'adf_accel_dev'?
286 | if (accel_dev)
| ^~~~~~~~~
| adf_accel_dev
drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:286:13: note: each undeclared identifier is reported only once for each function it appears in
vim +286 drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
255
256 static int adf_ctl_ioctl_dev_stop(struct file *fp, unsigned int cmd,
257 unsigned long arg)
258 {
259 int ret;
260 struct adf_user_cfg_ctl_data *ctl_data;
261
262 ctl_data = adf_ctl_alloc_resources(arg);
263 if (IS_ERR(ctl_data))
264 return PTR_ERR(ctl_data);
265
266 if (adf_devmgr_verify_id(ctl_data->device_id)) {
267 pr_err("QAT: Device %d not found\n", ctl_data->device_id);
268 ret = -ENODEV;
269 goto out;
270 }
271
272 ret = adf_ctl_is_device_in_use(ctl_data->device_id);
273 if (ret)
274 goto out;
275
276 if (ctl_data->device_id == ADF_CFG_ALL_DEVICES)
277 pr_info("QAT: Stopping all acceleration devices.\n");
278 else
279 pr_info("QAT: Stopping acceleration device qat_dev%d.\n",
280 ctl_data->device_id);
281
282 adf_ctl_stop_devices(ctl_data->device_id);
283
284 out:
285 /* Release the reference acquired by adf_devmgr_get_dev_by_id() */
> 286 if (accel_dev)
287 adf_dev_put(accel_dev);
288
289 kfree(ctl_data);
290 return ret;
291 }
292
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3] dt-bindings: crypto: qcom,prng: Document TRNG on Nord SoC
From: Shawn Guo @ 2026-05-10 2:18 UTC (permalink / raw)
To: Herbert Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm, linux-crypto,
devicetree, linux-kernel, Shawn Guo
From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Document True Random Number Generator on Qualcomm Nord SoC.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
---
Changes in v3:
- Improve commit log to drop "compatible with qcom,trng" part
- Link to v2 (TRNG): https://lore.kernel.org/all/20260427012308.231350-1-shengchao.guo@oss.qualcomm.com/
Changes in v2:
- Improve commit log to make the compatibility explicit
- Add missing SoB
- Link to v1: https://lore.kernel.org/all/20260420025732.1240525-1-shengchao.guo@oss.qualcomm.com/
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index 41402599e9ab..1362a8b748a7 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -22,6 +22,7 @@ properties:
- qcom,ipq9574-trng
- qcom,kaanapali-trng
- qcom,milos-trng
+ - qcom,nord-trng
- qcom,qcs615-trng
- qcom,qcs8300-trng
- qcom,sa8255p-trng
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 8/8] ARM: Remove hacked-up asm/types.h header
From: Arnd Bergmann @ 2026-05-09 20:33 UTC (permalink / raw)
To: Eric Biggers, Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King
In-Reply-To: <20260509200503.GC11883@quark>
On Sat, May 9, 2026, at 22:05, Eric Biggers wrote:
> On Wed, Apr 22, 2026 at 07:17:04PM +0200, Ard Biesheuvel wrote:
>> From: Ard Biesheuvel <ardb@kernel.org>
>>
>> ARM has a special version of asm/types.h which contains overrides for
>> certain #define's related to the C types used to back C99 types such as
>> uint32_t and uintptr_t.
>>
>> This is only needed when pulling in system headers such as stdint.h
>> during the build, and this only happens when using NEON intrinsics,
>> for which there is now a dedicated header file.
>>
>> So drop this header entirely, and revert to the asm-generic one.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> This is actually a UAPI header. I guess it got put there accidentally
> and isn't actually needed there?
Yes, commit ed79c9d34f4f ("ARM: put types.h in uapi") has some
explanations.
I can't think of any case where this would actually be used
from userland, and lots of ways it could cause trouble in
theory, even if it never has in practice.
Arnd
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Eric Biggers @ 2026-05-09 20:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ard Biesheuvel, linux-arm-kernel, linux-crypto, linux-raid,
Ard Biesheuvel, Russell King, Arnd Bergmann
In-Reply-To: <20260423074712.GC31018@lst.de>
On Thu, Apr 23, 2026 at 09:47:12AM +0200, Christoph Hellwig wrote:
> On Wed, Apr 22, 2026 at 07:17:03PM +0200, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > arm_neon.h is a compiler header which needs some scaffolding to work
> > correctly in the linux context, and so it is better not to include it
> > directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
> > takes care of this.
>
>
> This could potentially clash with the raid6 library rework I'm doing
> for 7.2. Although git has become pretty good about renamed files, so
> maybe it won't be so bad.
>
I think this patch also breaks the userspace build of lib/raid6/. Which
is going away in Christoph's series anyway, but maybe it would make
sense to drop this patch (and patch 8 which depends on this, I think)
from this series for now? That would make it a bit easier to take the
rest through crc-next.
- Eric
^ permalink raw reply
* Re: [PATCH 8/8] ARM: Remove hacked-up asm/types.h header
From: Eric Biggers @ 2026-05-09 20:05 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-crypto, linux-raid, Ard Biesheuvel,
Christoph Hellwig, Russell King, Arnd Bergmann
In-Reply-To: <20260422171655.3437334-18-ardb+git@google.com>
On Wed, Apr 22, 2026 at 07:17:04PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> ARM has a special version of asm/types.h which contains overrides for
> certain #define's related to the C types used to back C99 types such as
> uint32_t and uintptr_t.
>
> This is only needed when pulling in system headers such as stdint.h
> during the build, and this only happens when using NEON intrinsics,
> for which there is now a dedicated header file.
>
> So drop this header entirely, and revert to the asm-generic one.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm/include/uapi/asm/types.h | 41 --------------------
> 1 file changed, 41 deletions(-)
>
This is actually a UAPI header. I guess it got put there accidentally
and isn't actually needed there?
- Eric
^ permalink raw reply
* Re: [PATCH v2] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
From: Eric Biggers @ 2026-05-09 18:41 UTC (permalink / raw)
To: linux-crypto
Cc: linux-kernel, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu,
linuxppc-dev, Michael Ellerman, Madhavan Srinivasan,
Nicholas Piggin, Christophe Leroy
In-Reply-To: <20260506030005.9698-1-ebiggers@kernel.org>
On Tue, May 05, 2026 at 08:00:05PM -0700, Eric Biggers wrote:
> MD5 is obsolete, is vulnerable to collision attacks, and is being
> replaced by SHA-256 in new systems. It doesn't make sense to continue
> to maintain architecture-optimized implementations of MD5. Effort
> should be spent on modern algorithms.
>
> Indeed, architecture-optimized MD5 code remains only for powerpc. It
> was already removed from mips and sparc, and it never existed for any
> other architecture (e.g. x86, arm, or arm64) in the first place.
> Earlier the decision was made to keep the powerpc MD5 code for a while
> anyway because of someone using it via AF_ALG via libkcapi-hasher
> (https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/)
>
> However, with AF_ALG itself now being on its way out due to its
> continuous stream of security vulnerabilities
> (https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/),
> it's also time to be a bit more forceful with nudging people towards
> userspace crypto code. It's always been the better solution anyway, and
> it's much more efficient if properly optimized code is used.
>
> Note that the md5-asm.S file contains no privileged instructions and
> could be run in userspace just fine.
>
> Thus, we now have two factors going against keeping the powerpc MD5
> code. Different people might weigh these two factors differently, but I
> think the two of them together make the removal the clear choice.
>
> Let's remove it.
>
> Acked-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is intended to be taken via libcrypto-next
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next
- Eric
^ permalink raw reply
* Re: [PATCH] hwrng: tpm: Do not enable by default
From: Jarkko Sakkinen @ 2026-05-09 15:18 UTC (permalink / raw)
To: Niedermayr, BENEDIKT
Cc: Kiszka, Jan, Peter Huewe, linux-integrity@vger.kernel.org,
Linux Kernel Mailing List, Ilias Apalodimas, Jens Wiklander,
OP-TEE TrustedFirmware, linux-crypto@vger.kernel.org, Bauer, Sven,
Zeschg, Thomas, Gylstorff, Quirin
In-Reply-To: <96df7b4d-cf1b-471d-9b4b-8741a80fbcc3@siemens.com>
On Wed, Apr 29, 2026 at 02:33:20PM +0000, Niedermayr, BENEDIKT wrote:
> On 10/27/25 20:51, Jarkko Sakkinen wrote:
> > On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
> >> the current time epoch to its NV storage every 4 seconds if there are
> >> commands sent to it. The 60 seconds periodic update of the entropy pool
> >> that the hwrng kthread does triggers this, causing about 4 writes per
> >> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
> >> for its backing NV storage.
> >>
> >> It is therefore better to make the user intentionally enable this,
> >> providing a chance to read the warning.
> >>
> >> [1] https://github.com/Microsoft/ms-tpm-20-ref
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >
> > Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
> > writes NVRAM, then the implementation is broken.
> >
> > Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
> > distantly relates on using NVRAM.
> >
> > [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
>
> Hi all,
>
> we recently also stumbled over this issue which led me here to this
> thread and maybe adding our observations helps to clarify things here a
> bit (hopefully) or at least augments the information related to firmware
> TPM based implementation based on ms-tpm-20-ref.
>
> Based on the optee_ftpm repo, as Jan already described, which currently
> references commit 98b60a44aba7 of [1] suffers this exact issue because
> of the NV_CLOCK_UPDATE_INTERVAL [2] which is set to "12" and issues a
> write for each command after ~4 seconds have passed.
>
> This config has been changed to "22" (on current master branch [3])
> which is the allowed maximum when following the TPM spec (chapter 36.3.2
> in [4]) which leads to round about 70 minutes, but optee_ftpm didn't
> move ahead to this commit, yet.
> This config exists for being able to adapt the write cycles to the
> specific wear conditions of the hardware.
>
> Moreover the ms-tpm-20-ref repo seems to not be maintained anymore and
> one should rather switch to [6].
>
> So there are currently firmware TPM implementations out there that lead
> to these frequent writes.
Really this would need a product and official bug bulletin for it to
even consider a workaround. Speculation does not count.
>
> AFAIK since the tpm-20-ref implementation basically only supports a file
> on disk or RAM backing storage, the optee_ftpm repo [5] provides it's
> own _plat_NV* implementations that replace the default ones and finally
> call OP-TEE's TEE_* secure storage API, which then routes to whatever
> backend OP-TEE is configured with (REE-FS or RPMB) – In our case the RPMB.
>
> Because there are currently implementations out there (e.g. start using
> optee_ftpm) it may make sense to add this information to the kernel
> config's help text at least?
Your first forum to report such issues is the TPM vendor.
>
> We are currently trying to bump optee_ftpm to use the more recent v1.84,
> but since we're no TCG member the PRs on github could get a bit
> adventurous (PR's not upstream, yet).
> Until then this is a valid issue that exists...
>
>
> [2]
> https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46cf5918400f6a/TPMCmd/tpm/include/TpmProfile.h#L199
>
>
> [3]
> https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46cf5918400f6a/TPMCmd/tpm/include/TpmProfile.h#L200
>
> [4]
> https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf
>
> [5] https://github.com/OP-TEE/optee_ftpm
>
> [6] https://github.com/TrustedComputingGroup/TPM
>
> BR,
> Benedikt
>
BR, Jarkko
^ permalink raw reply
* [PATCH 1/2] crypto: atmel-sha204a - drop __maybe_unused and of_match_ptr
From: Thorsten Blum @ 2026-05-09 10:11 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
Since MODULE_DEVICE_TABLE() keeps atmel_sha204a_dt_ids referenced, drop
the unnecessary __maybe_unused annotation. Also remove of_match_ptr()
because OF matching is stubbed out when CONFIG_OF=n.
Reformat atmel_sha204a_dt_ids to silence a checkpatch error and
atmel_sha204a_id for consistency.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha204a.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c
index ed7d69bf6890..6e6ac4770416 100644
--- a/drivers/crypto/atmel-sha204a.c
+++ b/drivers/crypto/atmel-sha204a.c
@@ -207,17 +207,17 @@ static void atmel_sha204a_remove(struct i2c_client *client)
kfree((void *)i2c_priv->hwrng.priv);
}
-static const struct of_device_id atmel_sha204a_dt_ids[] __maybe_unused = {
+static const struct of_device_id atmel_sha204a_dt_ids[] = {
{ .compatible = "atmel,atsha204", .data = &atsha204_quality },
{ .compatible = "atmel,atsha204a", },
- { /* sentinel */ }
+ { }
};
MODULE_DEVICE_TABLE(of, atmel_sha204a_dt_ids);
static const struct i2c_device_id atmel_sha204a_id[] = {
{ "atsha204", (kernel_ulong_t)&atsha204_quality },
{ "atsha204a" },
- { /* sentinel */ }
+ { }
};
MODULE_DEVICE_TABLE(i2c, atmel_sha204a_id);
@@ -227,7 +227,7 @@ static struct i2c_driver atmel_sha204a_driver = {
.id_table = atmel_sha204a_id,
.driver.name = "atmel-sha204a",
- .driver.of_match_table = of_match_ptr(atmel_sha204a_dt_ids),
+ .driver.of_match_table = atmel_sha204a_dt_ids,
};
static int __init atmel_sha204a_init(void)
^ permalink raw reply related
* [PATCH 2/2] crypto: atmel-ecc - drop CONFIG_OF guard and of_match_ptr
From: Thorsten Blum @ 2026-05-09 10:11 UTC (permalink / raw)
To: Thorsten Blum, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260509101155.2095-3-thorsten.blum@linux.dev>
Drop the CONFIG_OF preprocessor guard and remove of_match_ptr() because
OF matching is stubbed out when CONFIG_OF=n.
Reformat atmel_ecc_dt_ids for consistency.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-ecc.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/atmel-ecc.c b/drivers/crypto/atmel-ecc.c
index 3738a4eb8701..c15096676ac5 100644
--- a/drivers/crypto/atmel-ecc.c
+++ b/drivers/crypto/atmel-ecc.c
@@ -368,18 +368,12 @@ static void atmel_ecc_remove(struct i2c_client *client)
spin_unlock(&driver_data.i2c_list_lock);
}
-#ifdef CONFIG_OF
static const struct of_device_id atmel_ecc_dt_ids[] = {
- {
- .compatible = "atmel,atecc508a",
- }, {
- .compatible = "atmel,atecc608b",
- }, {
- /* sentinel */
- }
+ { .compatible = "atmel,atecc508a", },
+ { .compatible = "atmel,atecc608b", },
+ { }
};
MODULE_DEVICE_TABLE(of, atmel_ecc_dt_ids);
-#endif
static const struct i2c_device_id atmel_ecc_id[] = {
{ "atecc508a" },
@@ -391,7 +385,7 @@ MODULE_DEVICE_TABLE(i2c, atmel_ecc_id);
static struct i2c_driver atmel_ecc_driver = {
.driver = {
.name = "atmel-ecc",
- .of_match_table = of_match_ptr(atmel_ecc_dt_ids),
+ .of_match_table = atmel_ecc_dt_ids,
},
.probe = atmel_ecc_probe,
.remove = atmel_ecc_remove,
^ permalink raw reply related
* [PATCH] crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()
From: Giovanni Cabiddu @ 2026-05-09 7:09 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, vdronov, Giovanni Cabiddu, stable,
Ahsan Atta
The VF2PF interrupt handler queues PF-side response work that stores a
raw pointer to per-VF state (struct adf_accel_vf_info). Currently,
adf_disable_sriov() destroys per-VF mutexes and frees vf_info without
stopping new VF2PF work or waiting for in-flight workers to complete. A
concurrently scheduled or already queued worker can then dereference
freed memory.
This manifests as a use-after-free when KASAN is enabled:
BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0
Write of size 8 at addr 0000000000000260 by task kworker/24:2/...
Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat]
Call Trace:
kasan_report+0x119/0x140
mutex_lock+0x76/0xe0
adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat]
adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat]
adf_iov_send_resp+0x8c/0xe0 [intel_qat]
process_one_work+0x6ac/0xfd0
worker_thread+0x4dd/0xd30
kthread+0x326/0x410
ret_from_fork+0x33b/0x670
Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker
processing, and interrupt re-enabling during teardown. Set this flag
atomically with the hardware interrupt mask inside
adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE
cluster MSI-X interrupt and flush the PF response workqueue before
tearing down per-VF locks and state so all in-flight work completes
before vf_info is destroyed.
Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and
unmask all VF2PF interrupts under the same lock when SR-IOV is
re-enabled. This ensures the software flag and hardware state transition
atomically on both the enable and disable paths.
Cc: stable@vger.kernel.org
Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
---
.../intel/qat/qat_common/adf_accel_devices.h | 2 +
.../intel/qat/qat_common/adf_common_drv.h | 2 +
drivers/crypto/intel/qat/qat_common/adf_isr.c | 40 +++++++++++++++++++
.../crypto/intel/qat/qat_common/adf_sriov.c | 24 +++++++++--
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/intel/qat/qat_common/adf_accel_devices.h b/drivers/crypto/intel/qat/qat_common/adf_accel_devices.h
index 03a4e9690208..d9b2a1cf474e 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_accel_devices.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_accel_devices.h
@@ -480,6 +480,8 @@ struct adf_accel_dev {
struct {
/* protects VF2PF interrupts access */
spinlock_t vf2pf_ints_lock;
+ /* prevents VF2PF handling from racing with VF state teardown */
+ bool vf2pf_disabled;
/* vf_info is non-zero when SR-IOV is init'ed */
struct adf_accel_vf_info *vf_info;
} pf;
diff --git a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
index e918d9b5e4f2..955934a8dd03 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
@@ -118,6 +118,7 @@ void qat_comp_alg_callback(void *resp);
int adf_isr_resource_alloc(struct adf_accel_dev *accel_dev);
void adf_isr_resource_free(struct adf_accel_dev *accel_dev);
+void adf_isr_sync_ae_cluster(struct adf_accel_dev *accel_dev);
int adf_vf_isr_resource_alloc(struct adf_accel_dev *accel_dev);
void adf_vf_isr_resource_free(struct adf_accel_dev *accel_dev);
@@ -191,6 +192,7 @@ int adf_sriov_configure(struct pci_dev *pdev, int numvfs);
void adf_disable_sriov(struct adf_accel_dev *accel_dev);
void adf_reenable_sriov(struct adf_accel_dev *accel_dev);
void adf_enable_vf2pf_interrupts(struct adf_accel_dev *accel_dev, u32 vf_mask);
+void adf_enable_all_vf2pf_interrupts(struct adf_accel_dev *accel_dev, u32 num_vfs);
void adf_disable_all_vf2pf_interrupts(struct adf_accel_dev *accel_dev);
bool adf_recv_and_handle_pf2vf_msg(struct adf_accel_dev *accel_dev);
bool adf_recv_and_handle_vf2pf_msg(struct adf_accel_dev *accel_dev, u32 vf_nr);
diff --git a/drivers/crypto/intel/qat/qat_common/adf_isr.c b/drivers/crypto/intel/qat/qat_common/adf_isr.c
index 4639d7fd93e6..01be0f166efc 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_isr.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_isr.c
@@ -62,6 +62,24 @@ void adf_enable_vf2pf_interrupts(struct adf_accel_dev *accel_dev, u32 vf_mask)
unsigned long flags;
spin_lock_irqsave(&accel_dev->pf.vf2pf_ints_lock, flags);
+ if (!READ_ONCE(accel_dev->pf.vf2pf_disabled))
+ GET_PFVF_OPS(accel_dev)->enable_vf2pf_interrupts(pmisc_addr, vf_mask);
+ spin_unlock_irqrestore(&accel_dev->pf.vf2pf_ints_lock, flags);
+}
+
+void adf_enable_all_vf2pf_interrupts(struct adf_accel_dev *accel_dev, u32 num_vfs)
+{
+ void __iomem *pmisc_addr = adf_get_pmisc_base(accel_dev);
+ unsigned long flags;
+ u32 vf_mask;
+
+ if (!num_vfs)
+ return;
+
+ vf_mask = BIT_ULL(num_vfs) - 1;
+
+ spin_lock_irqsave(&accel_dev->pf.vf2pf_ints_lock, flags);
+ WRITE_ONCE(accel_dev->pf.vf2pf_disabled, false);
GET_PFVF_OPS(accel_dev)->enable_vf2pf_interrupts(pmisc_addr, vf_mask);
spin_unlock_irqrestore(&accel_dev->pf.vf2pf_ints_lock, flags);
}
@@ -72,6 +90,7 @@ void adf_disable_all_vf2pf_interrupts(struct adf_accel_dev *accel_dev)
unsigned long flags;
spin_lock_irqsave(&accel_dev->pf.vf2pf_ints_lock, flags);
+ WRITE_ONCE(accel_dev->pf.vf2pf_disabled, true);
GET_PFVF_OPS(accel_dev)->disable_all_vf2pf_interrupts(pmisc_addr);
spin_unlock_irqrestore(&accel_dev->pf.vf2pf_ints_lock, flags);
}
@@ -174,6 +193,27 @@ static irqreturn_t adf_msix_isr_ae(int irq, void *dev_ptr)
return IRQ_NONE;
}
+void adf_isr_sync_ae_cluster(struct adf_accel_dev *accel_dev)
+{
+ struct adf_accel_pci *pci_dev_info = &accel_dev->accel_pci_dev;
+ struct adf_hw_device_data *hw_data = GET_HW_DATA(accel_dev);
+ u32 num_entries = pci_dev_info->msix_entries.num_entries;
+ struct adf_irq *irqs = pci_dev_info->msix_entries.irqs;
+ u32 irq_idx;
+ int irq;
+
+ if (!test_bit(ADF_STATUS_IRQ_ALLOCATED, &accel_dev->status) || !irqs)
+ return;
+
+ irq_idx = num_entries > 1 ? hw_data->num_banks : 0;
+ if (irq_idx >= num_entries || !irqs[irq_idx].enabled)
+ return;
+
+ irq = pci_irq_vector(pci_dev_info->pci_dev, hw_data->num_banks);
+ if (irq >= 0)
+ synchronize_irq(irq);
+}
+
static void adf_free_irqs(struct adf_accel_dev *accel_dev)
{
struct adf_accel_pci *pci_dev_info = &accel_dev->accel_pci_dev;
diff --git a/drivers/crypto/intel/qat/qat_common/adf_sriov.c b/drivers/crypto/intel/qat/qat_common/adf_sriov.c
index 8bf0fe1fcb4d..646f78009ccc 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_sriov.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_sriov.c
@@ -26,6 +26,9 @@ static void adf_iov_send_resp(struct work_struct *work)
u32 vf_nr = vf_info->vf_nr;
bool ret;
+ if (READ_ONCE(accel_dev->pf.vf2pf_disabled))
+ goto out;
+
mutex_lock(&vf_info->pfvf_mig_lock);
ret = adf_recv_and_handle_vf2pf_msg(accel_dev, vf_nr);
if (ret)
@@ -33,20 +36,33 @@ static void adf_iov_send_resp(struct work_struct *work)
adf_enable_vf2pf_interrupts(accel_dev, 1 << vf_nr);
mutex_unlock(&vf_info->pfvf_mig_lock);
+out:
kfree(pf2vf_resp);
}
void adf_schedule_vf2pf_handler(struct adf_accel_vf_info *vf_info)
{
+ struct adf_accel_dev *accel_dev = vf_info->accel_dev;
struct adf_pf2vf_resp *pf2vf_resp;
+ if (READ_ONCE(accel_dev->pf.vf2pf_disabled))
+ return;
+
pf2vf_resp = kzalloc_obj(*pf2vf_resp, GFP_ATOMIC);
if (!pf2vf_resp)
return;
pf2vf_resp->vf_info = vf_info;
INIT_WORK(&pf2vf_resp->pf2vf_resp_work, adf_iov_send_resp);
- queue_work(pf2vf_resp_wq, &pf2vf_resp->pf2vf_resp_work);
+
+ if (!queue_work(pf2vf_resp_wq, &pf2vf_resp->pf2vf_resp_work))
+ kfree(pf2vf_resp);
+}
+
+static void adf_flush_pf2vf_resp_wq(void)
+{
+ if (pf2vf_resp_wq)
+ flush_workqueue(pf2vf_resp_wq);
}
static int adf_enable_sriov(struct adf_accel_dev *accel_dev)
@@ -75,7 +91,7 @@ static int adf_enable_sriov(struct adf_accel_dev *accel_dev)
hw_data->configure_iov_threads(accel_dev, true);
/* Enable VF to PF interrupts for all VFs */
- adf_enable_vf2pf_interrupts(accel_dev, BIT_ULL(totalvfs) - 1);
+ adf_enable_all_vf2pf_interrupts(accel_dev, totalvfs);
/*
* Due to the hardware design, when SR-IOV and the ring arbiter
@@ -248,8 +264,10 @@ void adf_disable_sriov(struct adf_accel_dev *accel_dev)
adf_pf2vf_wait_for_restarting_complete(accel_dev);
pci_disable_sriov(accel_to_pci_dev(accel_dev));
- /* Disable VF to PF interrupts */
+ /* Block VF2PF work and disable VF to PF interrupts */
adf_disable_all_vf2pf_interrupts(accel_dev);
+ adf_isr_sync_ae_cluster(accel_dev);
+ adf_flush_pf2vf_resp_wq();
/* Clear Valid bits in AE Thread to PCIe Function Mapping */
if (hw_data->configure_iov_threads)
base-commit: 1e0613cd5cfb9fc6d622f0ae5ed33fafd184d259
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/2] crypto: qat - rename adf_ctl_drv.c to adf_module.c
From: Giovanni Cabiddu @ 2026-05-09 7:00 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, wangzhi, byu, w15303746062, vdronov,
Giovanni Cabiddu, Ahsan Atta
In-Reply-To: <20260509070340.12201-1-giovanni.cabiddu@intel.com>
Now that the character device and IOCTL interface have been removed,
adf_ctl_drv.c only contains module_init/module_exit hooks. Rename it
to adf_module.c to better reflect its purpose and rename the init/exit
functions accordingly.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
---
drivers/crypto/intel/qat/qat_common/Makefile | 2 +-
.../intel/qat/qat_common/{adf_ctl_drv.c => adf_module.c} | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
rename drivers/crypto/intel/qat/qat_common/{adf_ctl_drv.c => adf_module.c} (84%)
diff --git a/drivers/crypto/intel/qat/qat_common/Makefile b/drivers/crypto/intel/qat/qat_common/Makefile
index 9478111c8437..2b1649001518 100644
--- a/drivers/crypto/intel/qat/qat_common/Makefile
+++ b/drivers/crypto/intel/qat/qat_common/Makefile
@@ -9,7 +9,6 @@ intel_qat-y := adf_accel_engine.o \
adf_cfg.o \
adf_cfg_services.o \
adf_clock.o \
- adf_ctl_drv.o \
adf_dc.o \
adf_dev_mgr.o \
adf_gen2_config.o \
@@ -26,6 +25,7 @@ intel_qat-y := adf_accel_engine.o \
adf_hw_arbiter.o \
adf_init.o \
adf_isr.o \
+ adf_module.o \
adf_mstate_mgr.o \
adf_rl_admin.o \
adf_rl.o \
diff --git a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c b/drivers/crypto/intel/qat/qat_common/adf_module.c
similarity index 84%
rename from drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
rename to drivers/crypto/intel/qat/qat_common/adf_module.c
index f01f2946de6e..fccaa71eeedc 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_module.c
@@ -7,7 +7,7 @@
#include "adf_common_drv.h"
-static int __init adf_register_ctl_device_driver(void)
+static int __init adf_register_module(void)
{
if (adf_init_misc_wq())
goto err_misc_wq;
@@ -43,7 +43,7 @@ static int __init adf_register_ctl_device_driver(void)
return -EFAULT;
}
-static void __exit adf_unregister_ctl_device_driver(void)
+static void __exit adf_unregister_module(void)
{
adf_exit_misc_wq();
adf_exit_aer();
@@ -54,8 +54,8 @@ static void __exit adf_unregister_ctl_device_driver(void)
adf_clean_vf_map(false);
}
-module_init(adf_register_ctl_device_driver);
-module_exit(adf_unregister_ctl_device_driver);
+module_init(adf_register_module);
+module_exit(adf_unregister_module);
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Intel");
MODULE_DESCRIPTION("Intel(R) QuickAssist Technology");
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/2] crypto: qat - remove unused character device and IOCTLs
From: Giovanni Cabiddu @ 2026-05-09 7:00 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, wangzhi, byu, w15303746062, vdronov,
Giovanni Cabiddu, stable, Ahsan Atta
In-Reply-To: <20260509070340.12201-1-giovanni.cabiddu@intel.com>
The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs
for device configuration, start, stop, status query and enumeration.
These IOCTLs are not part of any public uAPI header and have no known
in-tree or out-of-tree users. Device lifecycle is already managed via
sysfs.
The ioctl interface also increases the attack surface and is the
subject of a number of bug reports.
Remove the character device, the IOCTL definitions, and the related
data structures (adf_dev_status_info, adf_user_cfg_key_val,
adf_user_cfg_section, adf_user_cfg_ctl_data). Drop the now-unused
adf_cfg_user.h header and strip adf_ctl_drv.c down to the minimal
module_init/module_exit hooks for workqueue, AER, and crypto/compression
algorithm registration.
Clean up leftover dead code that was only reachable from the removed
IOCTL paths: adf_cfg_del_all(), adf_devmgr_verify_id(),
adf_devmgr_get_num_dev(), and the ADF_CFG_ALL_DEVICES /
ADF_CFG_NO_DEVICE macros.
Additionally, drop the entry associated to QAT IOCTLs in
ioctl-number.rst.
Cc: stable@vger.kernel.org
Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
Reported-by: Zhi Wang <wangzhi@stu.xidian.edu.cn>
Reported-by: Bin Yu <byu@xidian.edu.cn>
Reported-by: MingYu Wang <w15303746062@163.com>
Closes: https://lore.kernel.org/all/61d6d499.ab89.19b9b7f3186.Coremail.wangzhi_xd@stu.xidian.edu.cn/
Link: https://lore.kernel.org/all/20260508034841.256794-1-w15303746062@163.com/
Link: https://lore.kernel.org/all/20260508023542.256299-1-w15303746062@163.com/
Link: https://lore.kernel.org/all/20260504025120.98242-1-w15303746062@163.com/
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
---
.../userspace-api/ioctl/ioctl-number.rst | 1 -
drivers/crypto/intel/qat/qat_common/adf_cfg.c | 10 -
drivers/crypto/intel/qat/qat_common/adf_cfg.h | 1 -
.../intel/qat/qat_common/adf_cfg_common.h | 29 --
.../intel/qat/qat_common/adf_cfg_user.h | 38 --
.../intel/qat/qat_common/adf_common_drv.h | 2 -
.../crypto/intel/qat/qat_common/adf_ctl_drv.c | 404 +-----------------
.../crypto/intel/qat/qat_common/adf_dev_mgr.c | 32 --
8 files changed, 1 insertion(+), 516 deletions(-)
delete mode 100644 drivers/crypto/intel/qat/qat_common/adf_cfg_user.h
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 331223761fff..29a08bc059dd 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -229,7 +229,6 @@ Code Seq# Include File Comments
<mailto:gregkh@linuxfoundation.org>
'a' all linux/atm*.h, linux/sonet.h ATM on linux
<http://lrcwww.epfl.ch/>
-'a' 00-0F drivers/crypto/qat/qat_common/adf_cfg_common.h conflict! qat driver
'b' 00-FF conflict! bit3 vme host bridge
<mailto:natalia@nikhefk.nikhef.nl>
'b' 00-0F linux/dma-buf.h conflict!
diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg.c b/drivers/crypto/intel/qat/qat_common/adf_cfg.c
index c202209f17d5..ea5d72d5090c 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_cfg.c
@@ -103,16 +103,6 @@ static void adf_cfg_section_del_all(struct list_head *head);
static void adf_cfg_section_del_all_except(struct list_head *head,
const char *section_name);
-void adf_cfg_del_all(struct adf_accel_dev *accel_dev)
-{
- struct adf_cfg_device_data *dev_cfg_data = accel_dev->cfg;
-
- down_write(&dev_cfg_data->lock);
- adf_cfg_section_del_all(&dev_cfg_data->sec_list);
- up_write(&dev_cfg_data->lock);
- clear_bit(ADF_STATUS_CONFIGURED, &accel_dev->status);
-}
-
void adf_cfg_del_all_except(struct adf_accel_dev *accel_dev,
const char *section_name)
{
diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg.h b/drivers/crypto/intel/qat/qat_common/adf_cfg.h
index 2afa6f0d15c5..108032b39242 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_cfg.h
@@ -34,7 +34,6 @@ void adf_cfg_dev_remove(struct adf_accel_dev *accel_dev);
void adf_cfg_dev_dbgfs_add(struct adf_accel_dev *accel_dev);
void adf_cfg_dev_dbgfs_rm(struct adf_accel_dev *accel_dev);
int adf_cfg_section_add(struct adf_accel_dev *accel_dev, const char *name);
-void adf_cfg_del_all(struct adf_accel_dev *accel_dev);
void adf_cfg_del_all_except(struct adf_accel_dev *accel_dev,
const char *section_name);
int adf_cfg_add_key_value_param(struct adf_accel_dev *accel_dev,
diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg_common.h b/drivers/crypto/intel/qat/qat_common/adf_cfg_common.h
index 81e9e9d7eccd..dd0e40971928 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg_common.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_cfg_common.h
@@ -4,7 +4,6 @@
#define ADF_CFG_COMMON_H_
#include <linux/types.h>
-#include <linux/ioctl.h>
#define ADF_CFG_MAX_STR_LEN 64
#define ADF_CFG_MAX_KEY_LEN_IN_BYTES ADF_CFG_MAX_STR_LEN
@@ -12,10 +11,7 @@
#define ADF_CFG_MAX_SECTION_LEN_IN_BYTES ADF_CFG_MAX_STR_LEN
#define ADF_CFG_BASE_DEC 10
#define ADF_CFG_BASE_HEX 16
-#define ADF_CFG_ALL_DEVICES 0xFE
-#define ADF_CFG_NO_DEVICE 0xFF
#define ADF_CFG_AFFINITY_WHATEVER 0xFF
-#define MAX_DEVICE_NAME_SIZE 32
#define ADF_MAX_DEVICES (32 * 32)
#define ADF_DEVS_ARRAY_SIZE BITS_TO_LONGS(ADF_MAX_DEVICES)
@@ -51,29 +47,4 @@ enum adf_device_type {
DEV_420XX,
DEV_6XXX,
};
-
-struct adf_dev_status_info {
- enum adf_device_type type;
- __u32 accel_id;
- __u32 instance_id;
- __u8 num_ae;
- __u8 num_accel;
- __u8 num_logical_accel;
- __u8 banks_per_accel;
- __u8 state;
- __u8 bus;
- __u8 dev;
- __u8 fun;
- char name[MAX_DEVICE_NAME_SIZE];
-};
-
-#define ADF_CTL_IOC_MAGIC 'a'
-#define IOCTL_CONFIG_SYS_RESOURCE_PARAMETERS _IOW(ADF_CTL_IOC_MAGIC, 0, \
- struct adf_user_cfg_ctl_data)
-#define IOCTL_STOP_ACCEL_DEV _IOW(ADF_CTL_IOC_MAGIC, 1, \
- struct adf_user_cfg_ctl_data)
-#define IOCTL_START_ACCEL_DEV _IOW(ADF_CTL_IOC_MAGIC, 2, \
- struct adf_user_cfg_ctl_data)
-#define IOCTL_STATUS_ACCEL_DEV _IOW(ADF_CTL_IOC_MAGIC, 3, __u32)
-#define IOCTL_GET_NUM_DEVICES _IOW(ADF_CTL_IOC_MAGIC, 4, __s32)
#endif
diff --git a/drivers/crypto/intel/qat/qat_common/adf_cfg_user.h b/drivers/crypto/intel/qat/qat_common/adf_cfg_user.h
deleted file mode 100644
index 421f4fb8b4dd..000000000000
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg_user.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/* SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0-only) */
-/* Copyright(c) 2014 - 2020 Intel Corporation */
-#ifndef ADF_CFG_USER_H_
-#define ADF_CFG_USER_H_
-
-#include "adf_cfg_common.h"
-#include "adf_cfg_strings.h"
-
-struct adf_user_cfg_key_val {
- char key[ADF_CFG_MAX_KEY_LEN_IN_BYTES];
- char val[ADF_CFG_MAX_VAL_LEN_IN_BYTES];
- union {
- struct adf_user_cfg_key_val *next;
- __u64 padding3;
- };
- enum adf_cfg_val_type type;
-} __packed;
-
-struct adf_user_cfg_section {
- char name[ADF_CFG_MAX_SECTION_LEN_IN_BYTES];
- union {
- struct adf_user_cfg_key_val *params;
- __u64 padding1;
- };
- union {
- struct adf_user_cfg_section *next;
- __u64 padding3;
- };
-} __packed;
-
-struct adf_user_cfg_ctl_data {
- union {
- struct adf_user_cfg_section *config_section;
- __u64 padding;
- };
- __u8 device_id;
-} __packed;
-#endif
diff --git a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
index fb0fd46a79b0..e918d9b5e4f2 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
@@ -70,8 +70,6 @@ void adf_devmgr_rm_dev(struct adf_accel_dev *accel_dev,
struct list_head *adf_devmgr_get_head(void);
struct adf_accel_dev *adf_devmgr_get_dev_by_id(u32 id);
struct adf_accel_dev *adf_devmgr_pci_to_accel_dev(struct pci_dev *pci_dev);
-int adf_devmgr_verify_id(u32 id);
-void adf_devmgr_get_num_dev(u32 *num);
int adf_devmgr_in_reset(struct adf_accel_dev *accel_dev);
int adf_dev_started(struct adf_accel_dev *accel_dev);
int adf_dev_restarting_notify(struct adf_accel_dev *accel_dev);
diff --git a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c b/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
index c2e6f0cb7480..f01f2946de6e 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
@@ -2,410 +2,13 @@
/* Copyright(c) 2014 - 2020 Intel Corporation */
#include <crypto/algapi.h>
+#include <linux/errno.h>
#include <linux/module.h>
-#include <linux/mutex.h>
-#include <linux/slab.h>
-#include <linux/fs.h>
-#include <linux/bitops.h>
-#include <linux/pci.h>
-#include <linux/cdev.h>
-#include <linux/uaccess.h>
-#include "adf_accel_devices.h"
#include "adf_common_drv.h"
-#include "adf_cfg.h"
-#include "adf_cfg_common.h"
-#include "adf_cfg_user.h"
-
-#define ADF_CFG_MAX_SECTION 512
-#define ADF_CFG_MAX_KEY_VAL 256
-
-#define DEVICE_NAME "qat_adf_ctl"
-
-static DEFINE_MUTEX(adf_ctl_lock);
-static long adf_ctl_ioctl(struct file *fp, unsigned int cmd, unsigned long arg);
-
-static const struct file_operations adf_ctl_ops = {
- .owner = THIS_MODULE,
- .unlocked_ioctl = adf_ctl_ioctl,
- .compat_ioctl = compat_ptr_ioctl,
-};
-
-static const struct class adf_ctl_class = {
- .name = DEVICE_NAME,
-};
-
-struct adf_ctl_drv_info {
- unsigned int major;
- struct cdev drv_cdev;
-};
-
-static struct adf_ctl_drv_info adf_ctl_drv;
-
-static void adf_chr_drv_destroy(void)
-{
- device_destroy(&adf_ctl_class, MKDEV(adf_ctl_drv.major, 0));
- cdev_del(&adf_ctl_drv.drv_cdev);
- class_unregister(&adf_ctl_class);
- unregister_chrdev_region(MKDEV(adf_ctl_drv.major, 0), 1);
-}
-
-static int adf_chr_drv_create(void)
-{
- dev_t dev_id;
- struct device *drv_device;
- int ret;
-
- if (alloc_chrdev_region(&dev_id, 0, 1, DEVICE_NAME)) {
- pr_err("QAT: unable to allocate chrdev region\n");
- return -EFAULT;
- }
-
- ret = class_register(&adf_ctl_class);
- if (ret)
- goto err_chrdev_unreg;
-
- adf_ctl_drv.major = MAJOR(dev_id);
- cdev_init(&adf_ctl_drv.drv_cdev, &adf_ctl_ops);
- if (cdev_add(&adf_ctl_drv.drv_cdev, dev_id, 1)) {
- pr_err("QAT: cdev add failed\n");
- goto err_class_destr;
- }
-
- drv_device = device_create(&adf_ctl_class, NULL,
- MKDEV(adf_ctl_drv.major, 0),
- NULL, DEVICE_NAME);
- if (IS_ERR(drv_device)) {
- pr_err("QAT: failed to create device\n");
- goto err_cdev_del;
- }
- return 0;
-err_cdev_del:
- cdev_del(&adf_ctl_drv.drv_cdev);
-err_class_destr:
- class_unregister(&adf_ctl_class);
-err_chrdev_unreg:
- unregister_chrdev_region(dev_id, 1);
- return -EFAULT;
-}
-
-static struct adf_user_cfg_ctl_data *adf_ctl_alloc_resources(unsigned long arg)
-{
- struct adf_user_cfg_ctl_data *cfg_data;
-
- cfg_data = memdup_user((void __user *)arg, sizeof(*cfg_data));
- if (IS_ERR(cfg_data))
- pr_err("QAT: failed to copy from user cfg_data.\n");
- return cfg_data;
-}
-
-static int adf_add_key_value_data(struct adf_accel_dev *accel_dev,
- const char *section,
- const struct adf_user_cfg_key_val *key_val)
-{
- if (key_val->type == ADF_HEX) {
- long *ptr = (long *)key_val->val;
- long val = *ptr;
-
- if (adf_cfg_add_key_value_param(accel_dev, section,
- key_val->key, (void *)val,
- key_val->type)) {
- dev_err(&GET_DEV(accel_dev),
- "failed to add hex keyvalue.\n");
- return -EFAULT;
- }
- } else {
- if (adf_cfg_add_key_value_param(accel_dev, section,
- key_val->key, key_val->val,
- key_val->type)) {
- dev_err(&GET_DEV(accel_dev),
- "failed to add keyvalue.\n");
- return -EFAULT;
- }
- }
- return 0;
-}
-
-static int adf_copy_key_value_data(struct adf_accel_dev *accel_dev,
- struct adf_user_cfg_ctl_data *ctl_data)
-{
- struct adf_user_cfg_key_val key_val;
- struct adf_user_cfg_key_val *params_head;
- struct adf_user_cfg_section section, *section_head;
- int i, j;
-
- section_head = ctl_data->config_section;
-
- for (i = 0; section_head && i < ADF_CFG_MAX_SECTION; i++) {
- if (copy_from_user(§ion, (void __user *)section_head,
- sizeof(*section_head))) {
- dev_err(&GET_DEV(accel_dev),
- "failed to copy section info\n");
- goto out_err;
- }
-
- if (adf_cfg_section_add(accel_dev, section.name)) {
- dev_err(&GET_DEV(accel_dev),
- "failed to add section.\n");
- goto out_err;
- }
-
- params_head = section.params;
-
- for (j = 0; params_head && j < ADF_CFG_MAX_KEY_VAL; j++) {
- if (copy_from_user(&key_val, (void __user *)params_head,
- sizeof(key_val))) {
- dev_err(&GET_DEV(accel_dev),
- "Failed to copy keyvalue.\n");
- goto out_err;
- }
- if (adf_add_key_value_data(accel_dev, section.name,
- &key_val)) {
- goto out_err;
- }
- params_head = key_val.next;
- }
- section_head = section.next;
- }
- return 0;
-out_err:
- adf_cfg_del_all(accel_dev);
- return -EFAULT;
-}
-
-static int adf_ctl_ioctl_dev_config(struct file *fp, unsigned int cmd,
- unsigned long arg)
-{
- struct adf_user_cfg_ctl_data *ctl_data;
- struct adf_accel_dev *accel_dev;
- int ret = 0;
-
- ctl_data = adf_ctl_alloc_resources(arg);
- if (IS_ERR(ctl_data))
- return PTR_ERR(ctl_data);
-
- accel_dev = adf_devmgr_get_dev_by_id(ctl_data->device_id);
- if (!accel_dev) {
- ret = -EFAULT;
- goto out;
- }
-
- if (adf_dev_started(accel_dev)) {
- ret = -EFAULT;
- goto out;
- }
-
- if (adf_copy_key_value_data(accel_dev, ctl_data)) {
- ret = -EFAULT;
- goto out;
- }
- set_bit(ADF_STATUS_CONFIGURED, &accel_dev->status);
-out:
- kfree(ctl_data);
- return ret;
-}
-
-static int adf_ctl_is_device_in_use(int id)
-{
- struct adf_accel_dev *dev;
-
- list_for_each_entry(dev, adf_devmgr_get_head(), list) {
- if (id == dev->accel_id || id == ADF_CFG_ALL_DEVICES) {
- if (adf_devmgr_in_reset(dev) || adf_dev_in_use(dev)) {
- dev_info(&GET_DEV(dev),
- "device qat_dev%d is busy\n",
- dev->accel_id);
- return -EBUSY;
- }
- }
- }
- return 0;
-}
-
-static void adf_ctl_stop_devices(u32 id)
-{
- struct adf_accel_dev *accel_dev;
-
- list_for_each_entry(accel_dev, adf_devmgr_get_head(), list) {
- if (id == accel_dev->accel_id || id == ADF_CFG_ALL_DEVICES) {
- if (!adf_dev_started(accel_dev))
- continue;
-
- /* First stop all VFs */
- if (!accel_dev->is_vf)
- continue;
-
- adf_dev_down(accel_dev);
- }
- }
-
- list_for_each_entry(accel_dev, adf_devmgr_get_head(), list) {
- if (id == accel_dev->accel_id || id == ADF_CFG_ALL_DEVICES) {
- if (!adf_dev_started(accel_dev))
- continue;
-
- adf_dev_down(accel_dev);
- }
- }
-}
-
-static int adf_ctl_ioctl_dev_stop(struct file *fp, unsigned int cmd,
- unsigned long arg)
-{
- int ret;
- struct adf_user_cfg_ctl_data *ctl_data;
-
- ctl_data = adf_ctl_alloc_resources(arg);
- if (IS_ERR(ctl_data))
- return PTR_ERR(ctl_data);
-
- if (adf_devmgr_verify_id(ctl_data->device_id)) {
- pr_err("QAT: Device %d not found\n", ctl_data->device_id);
- ret = -ENODEV;
- goto out;
- }
-
- ret = adf_ctl_is_device_in_use(ctl_data->device_id);
- if (ret)
- goto out;
-
- if (ctl_data->device_id == ADF_CFG_ALL_DEVICES)
- pr_info("QAT: Stopping all acceleration devices.\n");
- else
- pr_info("QAT: Stopping acceleration device qat_dev%d.\n",
- ctl_data->device_id);
-
- adf_ctl_stop_devices(ctl_data->device_id);
-
-out:
- kfree(ctl_data);
- return ret;
-}
-
-static int adf_ctl_ioctl_dev_start(struct file *fp, unsigned int cmd,
- unsigned long arg)
-{
- int ret;
- struct adf_user_cfg_ctl_data *ctl_data;
- struct adf_accel_dev *accel_dev;
-
- ctl_data = adf_ctl_alloc_resources(arg);
- if (IS_ERR(ctl_data))
- return PTR_ERR(ctl_data);
-
- ret = -ENODEV;
- accel_dev = adf_devmgr_get_dev_by_id(ctl_data->device_id);
- if (!accel_dev)
- goto out;
-
- dev_info(&GET_DEV(accel_dev),
- "Starting acceleration device qat_dev%d.\n",
- ctl_data->device_id);
-
- ret = adf_dev_up(accel_dev, false);
-
- if (ret) {
- dev_err(&GET_DEV(accel_dev), "Failed to start qat_dev%d\n",
- ctl_data->device_id);
- adf_dev_down(accel_dev);
- }
-out:
- kfree(ctl_data);
- return ret;
-}
-
-static int adf_ctl_ioctl_get_num_devices(struct file *fp, unsigned int cmd,
- unsigned long arg)
-{
- u32 num_devices = 0;
-
- adf_devmgr_get_num_dev(&num_devices);
- if (copy_to_user((void __user *)arg, &num_devices, sizeof(num_devices)))
- return -EFAULT;
-
- return 0;
-}
-
-static int adf_ctl_ioctl_get_status(struct file *fp, unsigned int cmd,
- unsigned long arg)
-{
- struct adf_hw_device_data *hw_data;
- struct adf_dev_status_info dev_info;
- struct adf_accel_dev *accel_dev;
-
- if (copy_from_user(&dev_info, (void __user *)arg,
- sizeof(struct adf_dev_status_info))) {
- pr_err("QAT: failed to copy from user.\n");
- return -EFAULT;
- }
-
- accel_dev = adf_devmgr_get_dev_by_id(dev_info.accel_id);
- if (!accel_dev)
- return -ENODEV;
-
- hw_data = accel_dev->hw_device;
- dev_info.state = adf_dev_started(accel_dev) ? DEV_UP : DEV_DOWN;
- dev_info.num_ae = hw_data->get_num_aes(hw_data);
- dev_info.num_accel = hw_data->get_num_accels(hw_data);
- dev_info.num_logical_accel = hw_data->num_logical_accel;
- dev_info.banks_per_accel = hw_data->num_banks
- / hw_data->num_logical_accel;
- strscpy(dev_info.name, hw_data->dev_class->name, sizeof(dev_info.name));
- dev_info.instance_id = hw_data->instance_id;
- dev_info.type = hw_data->dev_class->type;
- dev_info.bus = accel_to_pci_dev(accel_dev)->bus->number;
- dev_info.dev = PCI_SLOT(accel_to_pci_dev(accel_dev)->devfn);
- dev_info.fun = PCI_FUNC(accel_to_pci_dev(accel_dev)->devfn);
-
- if (copy_to_user((void __user *)arg, &dev_info,
- sizeof(struct adf_dev_status_info))) {
- dev_err(&GET_DEV(accel_dev), "failed to copy status.\n");
- return -EFAULT;
- }
- return 0;
-}
-
-static long adf_ctl_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
-{
- int ret;
-
- if (mutex_lock_interruptible(&adf_ctl_lock))
- return -EFAULT;
-
- switch (cmd) {
- case IOCTL_CONFIG_SYS_RESOURCE_PARAMETERS:
- ret = adf_ctl_ioctl_dev_config(fp, cmd, arg);
- break;
-
- case IOCTL_STOP_ACCEL_DEV:
- ret = adf_ctl_ioctl_dev_stop(fp, cmd, arg);
- break;
-
- case IOCTL_START_ACCEL_DEV:
- ret = adf_ctl_ioctl_dev_start(fp, cmd, arg);
- break;
-
- case IOCTL_GET_NUM_DEVICES:
- ret = adf_ctl_ioctl_get_num_devices(fp, cmd, arg);
- break;
-
- case IOCTL_STATUS_ACCEL_DEV:
- ret = adf_ctl_ioctl_get_status(fp, cmd, arg);
- break;
- default:
- pr_err_ratelimited("QAT: Invalid ioctl %d\n", cmd);
- ret = -EFAULT;
- break;
- }
- mutex_unlock(&adf_ctl_lock);
- return ret;
-}
static int __init adf_register_ctl_device_driver(void)
{
- if (adf_chr_drv_create())
- goto err_chr_dev;
-
if (adf_init_misc_wq())
goto err_misc_wq;
@@ -437,15 +40,11 @@ static int __init adf_register_ctl_device_driver(void)
err_aer:
adf_exit_misc_wq();
err_misc_wq:
- adf_chr_drv_destroy();
-err_chr_dev:
- mutex_destroy(&adf_ctl_lock);
return -EFAULT;
}
static void __exit adf_unregister_ctl_device_driver(void)
{
- adf_chr_drv_destroy();
adf_exit_misc_wq();
adf_exit_aer();
adf_exit_vf_wq();
@@ -453,7 +52,6 @@ static void __exit adf_unregister_ctl_device_driver(void)
qat_crypto_unregister();
qat_compression_unregister();
adf_clean_vf_map(false);
- mutex_destroy(&adf_ctl_lock);
}
module_init(adf_register_ctl_device_driver);
diff --git a/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c b/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
index e050de16ab5d..982f86ca4f54 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
@@ -329,38 +329,6 @@ struct adf_accel_dev *adf_devmgr_get_dev_by_id(u32 id)
return NULL;
}
-int adf_devmgr_verify_id(u32 id)
-{
- if (id == ADF_CFG_ALL_DEVICES)
- return 0;
-
- if (adf_devmgr_get_dev_by_id(id))
- return 0;
-
- return -ENODEV;
-}
-
-static int adf_get_num_dettached_vfs(void)
-{
- struct list_head *itr;
- int vfs = 0;
-
- mutex_lock(&table_lock);
- list_for_each(itr, &vfs_table) {
- struct vf_id_map *ptr =
- list_entry(itr, struct vf_id_map, list);
- if (ptr->bdf != ~0 && !ptr->attached)
- vfs++;
- }
- mutex_unlock(&table_lock);
- return vfs;
-}
-
-void adf_devmgr_get_num_dev(u32 *num)
-{
- *num = num_devices - adf_get_num_dettached_vfs();
-}
-
/**
* adf_dev_in_use() - Check whether accel_dev is currently in use
* @accel_dev: Pointer to acceleration device.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/2] crypto: qat - remove unused ioctl interface
From: Giovanni Cabiddu @ 2026-05-09 7:00 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, wangzhi, byu, w15303746062, vdronov,
Giovanni Cabiddu
The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs for
device configuration, start, stop, status query and enumeration. These
IOCTLs are not part of any public uAPI header and have no known in-tree
or out-of-tree users.
This ioctl interface increases the attack surface and is the subject of a
number of bug reports. Remove it entirely.
Patch 1 removes the character device, the IOCTL definitions, the related
data structures and headers. It strips adf_ctl_drv.c down to the
minimal module_init/module_exit hooks. This is marked for stable.
Patch 2 renames the now-minimal adf_ctl_drv.c to adf_module.c and
adjusts function names to match the new file name. This is not marked
for stable as it is a pure rename.
Changes since v1:
- Addressed comments from Sashiko: cleaned up leftover dead code
https://sashiko.dev/#/patchset/20260508091912.206913-1-giovanni.cabiddu%40intel.com
Giovanni Cabiddu (2):
crypto: qat - remove unused character device and IOCTLs
crypto: qat - rename adf_ctl_drv.c to adf_module.c
.../userspace-api/ioctl/ioctl-number.rst | 1 -
drivers/crypto/intel/qat/qat_common/Makefile | 2 +-
drivers/crypto/intel/qat/qat_common/adf_cfg.c | 10 -
drivers/crypto/intel/qat/qat_common/adf_cfg.h | 1 -
.../intel/qat/qat_common/adf_cfg_common.h | 29 --
.../intel/qat/qat_common/adf_cfg_user.h | 38 --
.../intel/qat/qat_common/adf_common_drv.h | 2 -
.../crypto/intel/qat/qat_common/adf_ctl_drv.c | 466 ------------------
.../crypto/intel/qat/qat_common/adf_dev_mgr.c | 32 --
.../crypto/intel/qat/qat_common/adf_module.c | 64 +++
10 files changed, 65 insertions(+), 580 deletions(-)
delete mode 100644 drivers/crypto/intel/qat/qat_common/adf_cfg_user.h
delete mode 100644 drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
create mode 100644 drivers/crypto/intel/qat/qat_common/adf_module.c
base-commit: f7dd32c5179d7755de18e21d5674b08f9e5cb180
--
2.54.0
^ permalink raw reply
* Re:Re: [PATCH] crypto: qat - fix use-after-free during concurrent device start and removal
From: w15303746062 @ 2026-05-09 6:40 UTC (permalink / raw)
To: Giovanni Cabiddu
Cc: herbert@gondor.apana.org.au, davem@davemloft.net, qat-linux,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Mingyu Wang
In-Reply-To: <af2r0f/20watHiCX@gcabiddu-mobl.ger.corp.intel.com>
From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Hi Giovanni,
Thank you for the update. Removing the unused IOCTL interface is indeed the cleanest and most effective way to eliminate these attack surfaces. I completely agree with this approach.
Thanks for CC'ing and acknowledging the report!
Best regards,
Mingyu
At 2026-05-08 17:24:33, "Giovanni Cabiddu" <giovanni.cabiddu@intel.com> wrote:
>Hi Mingyu,
>
>Thanks for your patches.
>
>The ioctl interface exposed by the QAT driver is not part of any public
>uAPI header and has no known users. I just sent a series that removes it
>entirely [1], which also eliminates this issue.
>
>[1] https://lore.kernel.org/all/20260508091912.206913-1-giovanni.cabiddu@intel.com/
>
>Regards,
>
>--
>Giovanni
>
>On Mon, May 04, 2026 at 03:51:20AM +0100, w15303746062@163.com wrote:
>> From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>>
>> A Use-After-Free (UAF) vulnerability was identified in the QAT driver's ioctl path. When handling commands like IOCTL_START_ACCEL_DEV, `adf_ctl_ioctl_dev_start()` retrieves the acceleration device using `adf_devmgr_get_dev_by_id()`.
>>
>> Previously, this lookup function iterated over the `accel_table` under the `table_lock`. However, once the target device was found, the lock was dropped and a bare pointer was returned without incrementing the device's reference count.
>>
>> This creates a critical race condition. If a concurrent thread removes the device (e.g., via device stop operations or PCIe hotplug) by calling `adf_devmgr_rm_dev()`, the device is removed from the list and its memory is subsequently freed. When the original ioctl thread resumes and attempts to acquire `accel_dev->state_lock` inside `adf_dev_up()`, it triggers a KASAN slab-out-of-bounds panic.
>>
>> Fix this by properly leveraging the existing `ref_count`. Increment the device's `ref_count` via `atomic_inc()` inside `adf_devmgr_get_dev_by_id()` while the `table_lock` is still held. All callers of `adf_devmgr_get_dev_by_id()` are then updated to safely release this reference using `atomic_dec(&accel_dev->ref_count)` once they are done interacting with the device.
>>
>> Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>> ---
>> drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c | 10 ++++++++++
>> drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c | 12 ++++++++++--
>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c b/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
>> index c2e6f0cb7480..4924b2bbb412 100644
>> --- a/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
>> +++ b/drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c
>> @@ -201,6 +201,9 @@ static int adf_ctl_ioctl_dev_config(struct file *fp, unsigned int cmd,
>> }
>> set_bit(ADF_STATUS_CONFIGURED, &accel_dev->status);
>> out:
>> + /* Release the reference acquired by adf_devmgr_get_dev_by_id() */
>> + if (accel_dev)
>> + atomic_dec(&accel_dev->ref_count);
>> kfree(ctl_data);
>> return ret;
>> }
>> @@ -310,6 +313,9 @@ static int adf_ctl_ioctl_dev_start(struct file *fp, unsigned int cmd,
>> adf_dev_down(accel_dev);
>> }
>> out:
>> + /* Release the reference acquired by adf_devmgr_get_dev_by_id() */
>> + if (accel_dev)
>> + atomic_dec(&accel_dev->ref_count);
>> kfree(ctl_data);
>> return ret;
>> }
>> @@ -360,8 +366,12 @@ static int adf_ctl_ioctl_get_status(struct file *fp, unsigned int cmd,
>> if (copy_to_user((void __user *)arg, &dev_info,
>> sizeof(struct adf_dev_status_info))) {
>> dev_err(&GET_DEV(accel_dev), "failed to copy status.\n");
>> + atomic_dec(&accel_dev->ref_count);
>> return -EFAULT;
>> }
>> +
>> + /* Release the reference acquired by adf_devmgr_get_dev_by_id() */
>> + atomic_dec(&accel_dev->ref_count);
>> return 0;
>> }
>>
>> diff --git a/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c b/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
>> index e050de16ab5d..321bea3cefce 100644
>> --- a/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
>> +++ b/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
>> @@ -320,6 +320,8 @@ struct adf_accel_dev *adf_devmgr_get_dev_by_id(u32 id)
>> struct adf_accel_dev *ptr =
>> list_entry(itr, struct adf_accel_dev, list);
>> if (ptr->accel_id == id) {
>> + /* Increment ref_count to prevent UAF during concurrent removal */
>> + atomic_inc(&ptr->ref_count);
>> mutex_unlock(&table_lock);
>> return ptr;
>> }
>> @@ -331,11 +333,17 @@ struct adf_accel_dev *adf_devmgr_get_dev_by_id(u32 id)
>>
>> int adf_devmgr_verify_id(u32 id)
>> {
>> + struct adf_accel_dev *accel_dev;
>> +
>> if (id == ADF_CFG_ALL_DEVICES)
>> return 0;
>>
>> - if (adf_devmgr_get_dev_by_id(id))
>> - return 0;
>> + accel_dev = adf_devmgr_get_dev_by_id(id);
>> + if (accel_dev) {
>> + /* Release the reference immediately as we only verify existence */
>> + atomic_dec(&accel_dev->ref_count);
>> + return 0;
>> + }
>>
>> return -ENODEV;
>> }
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v5 01/13] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Herbert Xu @ 2026-05-09 1:24 UTC (permalink / raw)
To: Harshal Dev
Cc: Bjorn Andersson, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam, cros-qcom-dts-watchers, Eric Biggers,
Dmitry Baryshkov, Jingyi Wang, Tengfei Fan, Bartosz Golaszewski,
David Wronek, Luca Weiss, Neil Armstrong, Melody Olvera,
Alexander Koskovich, Abel Vesa, Brian Masney, Neeraj Soni,
Gaurav Kashyap, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, Krzysztof Kozlowski, Konrad Dybcio, Kuldeep Singh,
Krzysztof Kozlowski
In-Reply-To: <CC0E438D-5544-4BB8-8512-7F93A7FA4DC1@oss.qualcomm.com>
On Fri, May 08, 2026 at 08:11:45PM +0530, Harshal Dev wrote:
>
> Can you please confirm for Bjorn once
> that you're not picking this up and he
> can pick it from his tree?
Bjorn, please feel free to pick this patch up.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC v2] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Pratik R. Sampat @ 2026-05-08 21:10 UTC (permalink / raw)
To: Tycho Andersen
Cc: ashish.kalra, thomas.lendacky, john.allen, herbert, davem,
linux-crypto, linux-kernel, aik, nikunj, michael.roth
In-Reply-To: <afitM-Ub50JsTCHz@tycho.pizza>
Hi Tycho,
Missed this one in my mailbox. Thanks for the review!
On 5/4/26 10:32 AM, Tycho Andersen wrote:
> On Fri, May 01, 2026 at 11:20:51AM -0400, Pratik R. Sampat wrote:
>> - failed_status (read-only): firmware-reported failure status from the
>> last operation, as returned alongside the status vectors
>
> "from the last operation" is not quite right here, it looks like it
> re-runs the STATUS command and reports that error?
That is correct. It runs the STATUS command and reports the status of the
verification operation. Probably better to phrase it as the "last verification
operation" instead?
>
>> + failed_status: Read only interface that reports the status of
>> + the verification operation.
>
> This should probably also note that it runs a fresh operation.
>
Ack.
> I was trying to think of a nice way to report the status of the last
> operation short of caching it, but I didn't come up with anything
> good. I don't think it's important enough to cache, the failure codes
> right now are all for things that would persist across runs.
>
Right, I didn't want to leave room for any ambiguity so avoided caching it for
one additional call.
If the failure status is set, we do fail the VERIFY op as well, but I wasn't
too sure how to report that failure without an additional interface like this.
--Pratik
^ permalink raw reply
* Re: [PATCH v4 0/7] Add RMPOPT support.
From: Borislav Petkov @ 2026-05-08 21:07 UTC (permalink / raw)
To: Ashish Kalra
Cc: tglx, mingo, dave.hansen, x86, hpa, seanjc, peterz,
thomas.lendacky, herbert, davem, ardb, pbonzini, aik,
Michael.Roth, KPrateek.Nayak, Tycho.Andersen, Nathan.Fontenot,
jackyli, pgonda, rientjes, jacobhxu, xin, pawan.kumar.gupta,
babu.moger, dyoung, nikunj, john.allen, darwi, linux-kernel,
linux-crypto, kvm, linux-coco
In-Reply-To: <cover.1775874970.git.ashish.kalra@amd.com>
On Mon, Apr 13, 2026 at 07:42:03PM +0000, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@amd.com>
>
> In the SEV-SNP architecture, hypervisor and non-SNP guests are subject
> to RMP checks on writes to provide integrity of SEV-SNP guest memory.
Sashiko has comments:
https://sashiko.dev/#/patchset/77153c889934972efcfc3d210251564f29abcf51.1775874970.git.ashish.kalra%40amd.com
Pls address them.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] crypto: use designated initializers for report structs
From: Thorsten Blum @ 2026-05-08 20:11 UTC (permalink / raw)
To: Eric Biggers; +Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20260508184013.GB4145640@google.com>
On Fri, May 08, 2026 at 06:40:13PM +0000, Eric Biggers wrote:
> On Fri, May 08, 2026 at 12:57:17PM +0200, Thorsten Blum wrote:
> > Use designated initializers for the report structs instead of clearing
> > the struct with memset() and then copying fixed strings with strscpy()
> > at runtime.
> >
> > This keeps the structs zero-initialized, lets the compiler diagnose
> > oversized string literals, and makes the code easier to read.
> >
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>
> Did you verify that none of these structs contain any implicit padding?
Yes, I checked the structs manually and with pahole, which also reported
no holes. The structs only use char[64] followed by unsigned ints, so
implicit padding shouldn't be an issue.
Thanks,
Thorsten
^ permalink raw reply
* Re: [PATCH net-next 2/5] net/rxrpc: Use local FCrypt-PCBC implementation
From: David Howells @ 2026-05-08 18:56 UTC (permalink / raw)
To: Eric Biggers
Cc: dhowells, netdev, linux-afs, Marc Dionne, linux-crypto,
linux-kernel, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
In-Reply-To: <20260508182318.GA4145640@google.com>
Eric Biggers <ebiggers@kernel.org> wrote:
> Also I'm waiting to see if the following patch gets merged:
> https://lore.kernel.org/netdev/20260502211340.446927-1-n7l8m4@u.northwestern.edu/
This is the favoured solution:
https://lore.kernel.org/netdev/af2kdW2F1gJ9U-Gg@v4bel/
The problem with the one you mentioned is that it does a mandatory copy, even
when it doesn't need to, for rxgk. I can benchmark that to see what the
performance impact it has.
David
^ permalink raw reply
* Re: [PATCH] crypto: use designated initializers for report structs
From: Eric Biggers @ 2026-05-08 18:40 UTC (permalink / raw)
To: Thorsten Blum; +Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20260508105717.472043-3-thorsten.blum@linux.dev>
On Fri, May 08, 2026 at 12:57:17PM +0200, Thorsten Blum wrote:
> Use designated initializers for the report structs instead of clearing
> the struct with memset() and then copying fixed strings with strscpy()
> at runtime.
>
> This keeps the structs zero-initialized, lets the compiler diagnose
> oversized string literals, and makes the code easier to read.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Did you verify that none of these structs contain any implicit padding?
- Eric
^ permalink raw reply
* Re: [PATCH net-next 2/5] net/rxrpc: Use local FCrypt-PCBC implementation
From: Eric Biggers @ 2026-05-08 18:23 UTC (permalink / raw)
To: David Howells
Cc: netdev, linux-afs, Marc Dionne, linux-crypto, linux-kernel,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
In-Reply-To: <286248.1778263325@warthog.procyon.org.uk>
On Fri, May 08, 2026 at 07:02:05PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
>
> > + if (skb_linearize(skb) < 0)
> > + return -ENOMEM;
>
> It seems skb_linearize() doesn't like being used in this fashion:
>
> kernel BUG at net/core/skbuff.c:2295!
> ...
> RIP: 0010:pskb_expand_head+0x41/0x220
> __pskb_pull_tail+0x5e/0x2f0
> rxkad_verify_packet_2+0xa8/0x190
> rxkad_verify_packet+0x12c/0x150
> rxrpc_recvmsg_data+0x1b0/0x470
> rxrpc_kernel_recv_data+0xa6/0x210
> afs_extract_data+0x5e/0x180
> yfs_deliver_fs_fetch_data64+0x10b/0x200
> afs_deliver_to_call+0xea/0x440
> afs_read_receive+0x8d/0x150
> afs_fetch_data_async_rx+0x12/0x20
> process_one_work+0x18e/0x2b0
>
> which corresponds to this:
>
> BUG_ON(skb_shared(skb));
>
> Presumably this is done because fcrypt_pcbc_decrypt() doesn't handle being
> called on a split buffer. I think this may require skb_copy() to be used
> instead, but that would need to be handled in rxrpc_input_call_event().
>
> I think rxkad_decrypt_response() should be okay because the encrypted data is
> extracted into a buffer first before being decrypted.
Yes, Marc pointed this out already. Thanks for the review and testing.
I just haven't had a chance to decide what to do with this patch yet.
It could be an unconditional skb_copy(), it could be decrypting the
fragmented skb in-place, or it could be fixing up the RxRPC code to no
longer take multiple references to the skb (so skb_shared() would no
longer be true). Let me know if you have a preference.
Also I'm waiting to see if the following patch gets merged:
https://lore.kernel.org/netdev/20260502211340.446927-1-n7l8m4@u.northwestern.edu/
That does the skb_copy() anyway, which would solve this problem.
- Eric
^ permalink raw reply
* Re: [PATCH net-next 2/5] net/rxrpc: Use local FCrypt-PCBC implementation
From: David Howells @ 2026-05-08 18:02 UTC (permalink / raw)
To: Eric Biggers
Cc: dhowells, netdev, linux-afs, Marc Dionne, linux-crypto,
linux-kernel, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
In-Reply-To: <20260428024400.123337-3-ebiggers@kernel.org>
Eric Biggers <ebiggers@kernel.org> wrote:
> + if (skb_linearize(skb) < 0)
> + return -ENOMEM;
It seems skb_linearize() doesn't like being used in this fashion:
kernel BUG at net/core/skbuff.c:2295!
...
RIP: 0010:pskb_expand_head+0x41/0x220
__pskb_pull_tail+0x5e/0x2f0
rxkad_verify_packet_2+0xa8/0x190
rxkad_verify_packet+0x12c/0x150
rxrpc_recvmsg_data+0x1b0/0x470
rxrpc_kernel_recv_data+0xa6/0x210
afs_extract_data+0x5e/0x180
yfs_deliver_fs_fetch_data64+0x10b/0x200
afs_deliver_to_call+0xea/0x440
afs_read_receive+0x8d/0x150
afs_fetch_data_async_rx+0x12/0x20
process_one_work+0x18e/0x2b0
which corresponds to this:
BUG_ON(skb_shared(skb));
Presumably this is done because fcrypt_pcbc_decrypt() doesn't handle being
called on a split buffer. I think this may require skb_copy() to be used
instead, but that would need to be handled in rxrpc_input_call_event().
I think rxkad_decrypt_response() should be okay because the encrypted data is
extracted into a buffer first before being decrypted.
David
^ permalink raw reply
* Re: [PATCH v5 01/13] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-05-08 14:41 UTC (permalink / raw)
To: Bjorn Andersson, Herbert Xu
Cc: David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Abel Vesa, Manivannan Sadhasivam,
cros-qcom-dts-watchers, Eric Biggers, Dmitry Baryshkov,
Jingyi Wang, Tengfei Fan, Bartosz Golaszewski, David Wronek,
Luca Weiss, Neil Armstrong, Melody Olvera, Alexander Koskovich,
Abel Vesa, Brian Masney, Neeraj Soni, Gaurav Kashyap,
linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Krzysztof Kozlowski, Konrad Dybcio, Kuldeep Singh,
Krzysztof Kozlowski
In-Reply-To: <b8805117-d54f-4e42-a7d4-6fa18af63e69@oss.qualcomm.com>
Hi Herbert,
On 7 May 2026 3:50:21 pm IST, Harshal Dev <harshal.dev@oss.qualcomm.com> wrote:
>Hi Bjorn,
>
>On 5/5/2026 2:17 PM, Herbert Xu wrote:
>> On Thu, Apr 16, 2026 at 05:29:18PM +0530, Harshal Dev wrote:
>>> The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
>>> power-domain and iface clock. Without enabling the iface clock and the
>>> associated power-domain the ICE hardware cannot function correctly and
>>> leads to unclocked hardware accesses being observed during probe.
>>>
>>> Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
>>> power-domain and iface clock for new devices (Eliza and Milos) introduced
>>> in the current release (7.1) with yet-to-stabilize ABI, while preserving
>>> backward compatibility for older devices.
>>>
>>> Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
>>> Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
>>> Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>> ---
>>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
>>> 1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> Patch applied. Thanks.
>
>Herbert has pulled out of picking this patch from his tree.
>As discussed, since this DT binding update relies on DTS changes in commits 12 and 13
>of these series, they should all go through the same tree.
>
>Can we aim to pick this series via the qcom-soc tree to ensure the binding and DTS changes
>are applied together? Since the 7.1 fixes window is open, I am hoping for this to be
>picked up this week or the next.
>
Can you please confirm for Bjorn once
that you're not picking this up and he
can pick it from his tree?
Many thanks,
Harshal
>Regards,
>Harshal
>
^ permalink raw reply
* Re: [PATCH] crypto : ecc - Fix carry overflow in vli multiplication
From: Stefan Berger @ 2026-05-08 14:36 UTC (permalink / raw)
To: Anastasia Tishchenko, Lukas Wunner, Ignat Korchagin, Herbert Xu,
David S . Miller
Cc: linux-crypto, linux-kernel
In-Reply-To: <20260508114844.29694-1-sv3iry@gmail.com>
On 5/8/26 7:48 AM, Anastasia Tishchenko wrote:
> The carry flag calculation fails when r01.m_high is saturated
> (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.
>
> The condition (r01.m_high < product.m_high) doesn't handle the case
> where r01.m_high == product.m_high and an additional carry exists
> from lower-bit overflow.
>
> Add proper handling for this boundary by accounting for the carry
> from the lower addition.
>
> This issue was discovered during formal verification of ECC functions.
Thanks!
>
> Signed-off-by: Anastasia Tishchenko <sv3iry@gmail.com>
> ---
> crypto/ecc.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/crypto/ecc.c b/crypto/ecc.c
> index 43b0def3a225..dfe96471407c 100644
> --- a/crypto/ecc.c
> +++ b/crypto/ecc.c
> @@ -427,7 +427,10 @@ static void vli_mult(u64 *result, const u64 *left, const u64 *right,
> product = mul_64_64(left[i], right[k - i]);
>
> r01 = add_128_128(r01, product);
> - r2 += (r01.m_high < product.m_high);
Maybe the following or something like lt_128(r01, product) would be
'better' replacing 'r01 < product':
if (cmp_128(r01, product) < 0)
r2++;
/* Compare two uint128_t; returns -1 if a<b, 0 if a == b, 1 otherwise */
static int cmp_128(uint128_t a, uint128_t b)
{
if (a.m_high < b.m_high)
return -1;
if (a.m_high > b.m_high)
return 1;
if (a.m_low < b.m_low)
return -1;
if (a.m_low > b.m_low)
return 1;
return 0;
}
/* r01 < product */
if (lt_128(r01, product))
r2++;
/* Check a < b; return 1 if a < b, 0 otherwise */
static int lt_128(uint128_t a, uint128_t b)
{
if (a.m_high < b.m_high)
return 1;
if (a.m_high > b.m_high)
return 0;
if (a.m_low < b.m_low)
return 1;
return 0;
}
> + if (r01.m_high != product.m_high)
> + r2 += (r01.m_high < product.m_high);
> + else
> + r2 += (r01.m_low < product.m_low);
> }
>
> result[k] = r01.m_low;
> @@ -488,7 +491,10 @@ static void vli_square(u64 *result, const u64 *left, unsigned int ndigits)
> }
>
> r01 = add_128_128(r01, product);
> - r2 += (r01.m_high < product.m_high);
> + if (r01.m_high != product.m_high)
> + r2 += (r01.m_high < product.m_high);
> + else
> + r2 += (r01.m_low < product.m_low);
> }
>
> result[k] = r01.m_low;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox