* Re: [RFC v2] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Tycho Andersen @ 2026-05-11 14:25 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: ashish.kalra, thomas.lendacky, john.allen, herbert, davem,
linux-crypto, linux-kernel, aik, nikunj, michael.roth
In-Reply-To: <673592c4-8eca-4b84-9f60-7020327d1afd@amd.com>
On Fri, May 08, 2026 at 05:10:52PM -0400, Pratik R. Sampat wrote:
> 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?
Hmm, I'm not sure what you mean here. The FW spec 1.58 table 132 says:
Command to request the firmware to return information regarding the
currently supported (available) mitigations, and then the verified
(processed and completed) mitigations. If DST_PADDR_EN is set,
DST_PADDR will be populated with the SNP_VERIFY_MITIGATION_DST_PADDR
structure.
so I don't think it has anything to do with the last VERIFY operation?
The spec is a bit messy here, though. Table 131 mentions a
MIT_REQ_CHECK operation, which I assume should really be _STATUS. It
describes what the output VECTOR should be for VERIFY in table 131,
but not what it is for STATUS. Table 132 suggests the output VECTOR is
the list of supported mitigations, which matches what I was seeing
when I played with this.
Tycho
^ permalink raw reply
* Re: [PATCH v5 01/13] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Bjorn Andersson @ 2026-05-11 14:17 UTC (permalink / raw)
To: Herbert Xu
Cc: Harshal Dev, 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: <af6MsD1wDs9EZl5q@gondor.apana.org.au>
On Sat, May 09, 2026 at 09:24:00AM +0800, Herbert Xu wrote:
> 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 Herbert, I've picked the binding up.
If you need it, you can find it at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260416-qcom_ice_power_and_clk_vote-v5-1-5ccf5d7e2846@oss.qualcomm.com
Regards,
Bjorn
> 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: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Christoph Hellwig @ 2026-05-11 12:28 UTC (permalink / raw)
To: Eric Biggers
Cc: Christoph Hellwig, Ard Biesheuvel, linux-arm-kernel, linux-crypto,
linux-raid, Ard Biesheuvel, Russell King, Arnd Bergmann
In-Reply-To: <20260509202354.GD11883@quark>
On Sat, May 09, 2026 at 01:23:54PM -0700, Eric Biggers wrote:
> I think this patch also breaks the userspace build of lib/raid6/. Which
> is going away in Christoph's series anyway,
Assuming we're overcoming the objections. Anyway, about to repost this,
and maybe Art is another voice for dropping the userspace build support
of the RAID code.
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix Use-After-Free in adf_ctl_ioctl_dev_start()
From: kernel test robot @ 2026-05-11 12:22 UTC (permalink / raw)
To: w15303746062, giovanni.cabiddu, herbert, davem
Cc: llvm, 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-rc3 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: loongarch-randconfig-001-20260510 (https://download.01.org/0day-ci/archive/20260511/202605112040.jcfTlYZH-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 5bac06718f502014fade905512f1d26d578a18f3)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260511/202605112040.jcfTlYZH-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/202605112040.jcfTlYZH-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:286:6: error: use of undeclared identifier 'accel_dev'
286 | if (accel_dev)
| ^~~~~~~~~
drivers/crypto/intel/qat/qat_common/adf_ctl_drv.c:287:15: error: use of undeclared identifier 'accel_dev'
287 | adf_dev_put(accel_dev);
| ^~~~~~~~~
2 errors generated.
vim +/accel_dev +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 2/2] crypto: qat - rename adf_ctl_drv.c to adf_module.c
From: Giovanni Cabiddu @ 2026-05-11 10:04 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, wangzhi, byu, w15303746062, vdronov,
Giovanni Cabiddu, Ahsan Atta
In-Reply-To: <20260511100854.29474-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 v3 1/2] crypto: qat - remove unused character device and IOCTLs
From: Giovanni Cabiddu @ 2026-05-11 10:04 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, wangzhi, byu, w15303746062, vdronov,
Giovanni Cabiddu, stable, Ahsan Atta
In-Reply-To: <20260511100854.29474-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(), adf_devmgr_get_dev_by_id(),
adf_get_vf_real_id() and the unused ADF_CFG 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 | 32 --
.../intel/qat/qat_common/adf_cfg_user.h | 38 --
.../intel/qat/qat_common/adf_common_drv.h | 3 -
.../crypto/intel/qat/qat_common/adf_ctl_drv.c | 404 +-----------------
.../crypto/intel/qat/qat_common/adf_dev_mgr.c | 70 ---
8 files changed, 1 insertion(+), 558 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..d63f4dcccbb5 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_cfg_common.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_cfg_common.h
@@ -4,18 +4,11 @@
#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
#define ADF_CFG_MAX_VAL_LEN_IN_BYTES ADF_CFG_MAX_STR_LEN
#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 +44,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..e8dd76751dfb 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
+++ b/drivers/crypto/intel/qat/qat_common/adf_common_drv.h
@@ -68,10 +68,7 @@ int adf_devmgr_add_dev(struct adf_accel_dev *accel_dev,
void adf_devmgr_rm_dev(struct adf_accel_dev *accel_dev,
struct adf_accel_dev *pf);
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..161863841a52 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_dev_mgr.c
@@ -45,19 +45,6 @@ static struct vf_id_map *adf_find_vf(u32 bdf)
return NULL;
}
-static int adf_get_vf_real_id(u32 fake)
-{
- struct list_head *itr;
-
- list_for_each(itr, &vfs_table) {
- struct vf_id_map *ptr =
- list_entry(itr, struct vf_id_map, list);
- if (ptr->fake_id == fake)
- return ptr->id;
- }
- return -1;
-}
-
/**
* adf_clean_vf_map() - Cleans VF id mappings
* @vf: flag indicating whether mappings is cleaned
@@ -304,63 +291,6 @@ struct adf_accel_dev *adf_devmgr_pci_to_accel_dev(struct pci_dev *pci_dev)
}
EXPORT_SYMBOL_GPL(adf_devmgr_pci_to_accel_dev);
-struct adf_accel_dev *adf_devmgr_get_dev_by_id(u32 id)
-{
- struct list_head *itr;
- int real_id;
-
- mutex_lock(&table_lock);
- real_id = adf_get_vf_real_id(id);
- if (real_id < 0)
- goto unlock;
-
- id = real_id;
-
- list_for_each(itr, &accel_table) {
- struct adf_accel_dev *ptr =
- list_entry(itr, struct adf_accel_dev, list);
- if (ptr->accel_id == id) {
- mutex_unlock(&table_lock);
- return ptr;
- }
- }
-unlock:
- mutex_unlock(&table_lock);
- 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 v3 0/2] crypto: qat - remove unused ioctl interface
From: Giovanni Cabiddu @ 2026-05-11 10:04 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
Changes since v2:
- Removed additional dead code: adf_devmgr_get_dev_by_id(),
adf_get_vf_real_id() and a few ADF_CFG unused macros
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 | 32 --
.../intel/qat/qat_common/adf_cfg_user.h | 38 --
.../intel/qat/qat_common/adf_common_drv.h | 3 -
.../crypto/intel/qat/qat_common/adf_ctl_drv.c | 466 ------------------
.../crypto/intel/qat/qat_common/adf_dev_mgr.c | 70 ---
.../crypto/intel/qat/qat_common/adf_module.c | 64 +++
10 files changed, 65 insertions(+), 622 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: powernv_rng_read: Oops: Kernel access of bad area, sig: 11 [#1]
From: Paul Menzel @ 2026-05-11 8:03 UTC (permalink / raw)
To: Madhavan Srinivasan, Olivia Mackall, Herbert Xu, Michael Ellerman,
Jason A. Donenfeld
Cc: linux-crypto, linuxppc-dev, LKML
In-Reply-To: <6f58b950-a997-4dd6-a1a2-95eb72009151@molgen.mpg.de>
Dear Madhavan, dear Jason,
Am 11.05.26 um 09:00 schrieb Paul Menzel:
> Am 07.05.26 um 04:40 schrieb Madhavan Srinivasan:
>>
>> On 5/6/26 7:31 PM, Paul Menzel wrote:
>
>>> After a long while, on the 8335-GCA POWER8 (raw) 0x4d0200
>>> opal:skiboot-5.4.8-5787ad3 PowerNV, I built Linux from Linus’ master
>>> branch and rebooted via kexec.
>>>
>>> ```
>>> [ 0.000000] Linux version 7.1.0-rc2+ (pmenzel@flughafenberlinbrandenburgwillybrandt.molgen.mpg.de) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Wed May 6 08:50:58 CEST 2026
>>> […]
>>> [ 17.901992] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
>>> [ 17.902011] BUG: Kernel NULL pointer dereference on read at 0x00000000
>>> [ 17.902018] Faulting instruction address: 0xc0000000000e7138
>>> [ 17.902027] Oops: Kernel access of bad area, sig: 11 [#1]
>>> [ 17.902034] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>> [ 17.902045] Modules linked in: powernv_rng(+) bnx2x ofpart ibmpowernv bfq mdio cmdlinepart powernv_flash ipmi_powernv ipmi_devintf mtd ipmi_msghandler at24(+) vmx_crypto opal_prd sch_fq_codel nfsd parport_pc ppdev auth_rpcgss nfs_acl lp lockd grace parport sunrpc autofs4 btrfs xor libblake2b raid6_pq ast drm_shmem_helper drm_client_lib i2c_algo_bit drm_kms_helper drm ahci drm_panel_orientation_quirks libahci
>>> [ 17.902185] CPU: 147 UID: 0 PID: 2626 Comm: hwrng Not tainted 7.1.0-rc2+ #3 PREEMPTLAZY
>>> [ 17.902197] Hardware name: 8335-GCA POWER8 (raw) 0x4d0200 opal:skiboot-5.4.8-5787ad3 PowerNV
>>> [ 17.902204] NIP: c0000000000e7138 LR: c00800001ec8013c CTR: c0000000000e70fc
>>> [ 17.902212] REGS: c000000092913c50 TRAP: 0300 Not tainted (7.1.0-rc2+)
>>> [ 17.902222] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 44420220 XER: 20000000
>>> [ 17.902269] CFAR: c00800001ec8026c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
>>> GPR00: c00800001ec8013c c000000092913ef0 c000000001c18100 c00000002222d900
>>> GPR04: c00000002222d900 0000000000000080 0000000000000001 0000000000000000
>>> GPR08: 0000000000000000 c000000002212000 c0000000951e1780 c00800001ec80258
>>> GPR12: c0000000000e70fc c00000ffff6fd700 c0000000001d11c0 c00000001b99b9c0
>>> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> GPR24: 0000000000000000 c000000002fe6a58 0000000000000000 0000000000000000
>>> GPR28: c000000002fe6a20 0000000000000010 000000000000000f c00000002222d900
>>> [ 17.902406] NIP [c0000000000e7138] pnv_get_random_long+0x3c/0x114
>>> [ 17.902426] LR [c00800001ec8013c] powernv_rng_read+0x78/0xc4 [powernv_rng]
>>> [ 17.902444] Call Trace:
>>> [ 17.902448] [c000000092913ef0] [c000000092913f30] 0xc000000092913f30 (unreliable)
>>> [ 17.902463] [c000000092913f30] [c000000000decd58] hwrng_fillfn+0xd4/0x3dc
>>> [ 17.902484] [c000000092913f90] [c0000000001d1328] kthread+0x170/0x1a4
>>> [ 17.902498] [c000000092913fe0] [c00000000000d030] start_kernel_thread+0x14/0x18
>>> [ 17.902513] Code: 60000000 7d2000a6 71290010 418200bc e94d0908 812a0000 39290001 912a0000 e90d0030 3d220060 39299f00 7d08482a <e9280000> 7c0004ac e8e90000 0c070000
>>> [ 17.902569] ---[ end trace 0000000000000000 ]---
>>> [ 18.008801] pstore: backend (nvram) writing error (-1)
>>>
>>> [ 18.015458] note: hwrng[2626] exited with irqs disabled
>>> [ 18.015483] note: hwrng[2626] exited with preempt_count 1
>>> ```
>>>
>>> Please find the output of `dmesg` attached.
>>
>> This is from my yesterday's boot test log in my P8, did not see this
>> fail.
>>
>> root@ltcppm1:~# uname -a
>> Linux ltcppm1.ltc.tadn.ibm.com 7.1.0-rc2-00021-gf583bd5f64d4 #1 SMP
>> PREEMPT Wed May 6 00:55:45 EDT 2026 ppc64le GNU/Linux
>> root@ltcppm1:~# dmesg
>> [ 0.000000] [ T0] random: crng init done
>> [ 0.000000] [ T0] hash-mmu: Page sizes from device-tree:
>> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
>> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=16, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=7
>> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=24, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=56
>> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1
>> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=8
>> [ 0.000000] [ T0] hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0
>> [ 0.000000] [ T0] hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x000007ff, tlbiel=0, penc=3
>> [ 0.000000] [ T0] Enabling pkeys with max key count 32
>> [ 0.000000] [ T0] Activating Kernel Userspace Access Prevention
>> [ 0.000000] [ T0] Activating Kernel Userspace Execution Prevention
>> [ 0.000000] [ T0] hash-mmu: Page orders: linear mapping = 24, virtual = 16, io = 16, vmemmap = 24
>> [ 0.000000] [ T0] hash-mmu: Using 1TB segments
>> [ 0.000000] [ T0] hash-mmu: Initializing hash mmu with SLB
>> [ 0.000000] [ T0] Linux version 7.1.0-rc2-00021-gf583bd5f64d4 (root@ltcppm1.ltc.tadn.ibm.com) (gcc (GCC) 16.1.1 20260501 (Red Hat 16.1.1-1), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT Wed May 6
>> 00:55:45 EDT 2026
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000039c00000..0x000000003b6801ff (27136 KiB) map non-reusable ibm,firmware-allocs-memory@39c00000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000800000000..0x0000000800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@800000000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001000000000..0x0000001000dc01ff (14080 KiB) map non-reusable ibm,firmware-allocs-memory@1000000000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001800000000..0x0000001800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@1800000000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030000000..0x00000000302fffff (3072 KiB) map non-reusable ibm,firmware-code@30000000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031000000..0x0000000031bfffff (12288 KiB) map non-reusable ibm,firmware-data@31000000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030300000..0x0000000030ffffff (13312 KiB) map non-reusable ibm,firmware-heap@30300000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031c00000..0x0000000033fdffff (36736 KiB) map non-reusable ibm,firmware-stacks@31c00000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd510000..0x0000001ffd69ffff (1600 KiB) map non-reusable ibm,hbrt-code-image@1ffd510000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd6a0000..0x0000001ffd6fffff (384 KiB) map non-reusable ibm,hbrt-target-image@1ffd6a0000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd700000..0x0000001ffd7fffff (1024 KiB) map non-reusable ibm,hbrt-vpd-image@1ffd700000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffda00000..0x0000001ffdafffff (1024 KiB) map non-reusable ibm,slw-image@1ffda00000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffde00000..0x0000001ffdefffff (1024 KiB) map non-reusable ibm,slw-image@1ffde00000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe200000..0x0000001ffe2fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe200000
>> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe600000..0x0000001ffe6fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe600000
>> [ 0.000000] [ T0] Found initrd at 0xc000000006a40000:0xc00000000815ae9e
>> [ 0.000000] [ T0] Hardware name: 8247-22L POWER8E (raw) 0x4b0201 opal:skiboot-v5.4.12 PowerNV
>> [ 0.000000] [ T0] printk: legacy bootconsole [udbg0] enabled
>> [ 0.000000] [ T0] CPU maps initialized for 8 threads per core
>> [ 0.000000] [ T0] (thread shift is 3)
>>>> But I my opal version 5.4.12.
>>
>> Thanks for reporting the issue, will have an look at it.
>
> I bisected it to a change between 5.19-rc3 and 5.19-rc4, and merge
> commit 8100775d59a6 (Merge tag 'powerpc-5.19-3' of git://git.kernel.org/
> pub/scm/linux/kernel/git/powerpc/linux) [1] indeed has rng related changes
>
>> - Three fixes to wire up our various RNGs earlier in boot so they're
>> available for use in the initial seeding in random_init().
I confirmed, that commit f3eac426657d (powerpc/powernv: wire up rng
during setup_arch) [2] introduced the Oops.
>> [ 0.000000] [ T0] Allocated 4608 bytes for 160 pacas
>> [ 0.000000] [ T0]
>> -----------------------------------------------------
>>
>> .......
>>
>> [ 37.407674] [ T900] audit: type=1130 audit(1778043621.931:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
>> terminal=? res=success'
>> [ 37.413015] [ T900] audit: type=1130 audit(1778043621.937:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
>> [ 38.448156] [ T2286] powernv_rng: Registered powernv hwrng.
>> [ 38.575227] [ T2264] tg3 0005:09:00.1 enP5p9s0f1: renamed from eth1
>> [ 38.582176] [ T2223] tg3 0005:09:00.2 enP5p9s0f2: renamed from eth2
>> ........
>>
>> ////cpuinfo output
>>
>> processor : 159
>>
>> cpu : POWER8E (raw), altivec supported
>> clock : 2061.000000MHz
>> revision : 2.1 (pvr 004b 0201)
>>
>> timebase : 512000000
>> platform : PowerNV
>> model : 8247-22L
>> machine : PowerNV 8247-22L
>> firmware : OPAL
>> MMU : Hash
>>
>>
>> But my system opal version 5.4.12.
>> Thanks for reporting the issue, will have an look at it.
>
> Thank you.
Kind regards,
Paul
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8100775d59a6789c3c6c309de26fac52f129cba8
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3eac426657d985b97c92fa5f7ae1d43f04721f3
^ permalink raw reply
* Re: [PATCH] crypto: safexcel - Fix potential memory leak in safexcel_pci_probe()
From: Antoine Tenart @ 2026-05-11 7:46 UTC (permalink / raw)
To: Abdun Nihaal
Cc: atenart, herbert, davem, linux-crypto, linux-kernel, pvanleeuwen
In-Reply-To: <20260508090347.74176-1-nihaal@cse.iitm.ac.in>
On Fri, May 08, 2026 at 02:33:45PM +0530, Abdun Nihaal wrote:
> The memory allocated for priv in safexcel_pci_probe() is not freed in the
> error paths, as well as in the PCI remove function. Fix this by using
> device managed allocation.
>
> Fixes: 625f269a5a7a ("crypto: inside-secure - add support for PCI based FPGA development board")
> Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in>
Reviewed-by: Antoine Tenart <atenart@kernel.org>
Thanks!
> ---
> Compile tested only. Issue found using static analysis.
>
> drivers/crypto/inside-secure/safexcel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/inside-secure/safexcel.c b/drivers/crypto/inside-secure/safexcel.c
> index fb4936e7afa2..2bd8641a07b3 100644
> --- a/drivers/crypto/inside-secure/safexcel.c
> +++ b/drivers/crypto/inside-secure/safexcel.c
> @@ -1893,7 +1893,7 @@ static int safexcel_pci_probe(struct pci_dev *pdev,
> ent->vendor, ent->device, ent->subvendor,
> ent->subdevice, ent->driver_data);
>
> - priv = kzalloc_obj(*priv);
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v16 00/12] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Bartosz Golaszewski @ 2026-05-11 7:38 UTC (permalink / raw)
To: Vinod Koul
Cc: Bartosz Golaszewski, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, Bartosz Golaszewski,
Dmitry Baryshkov, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <ditrkd5jcxlx7onykxh6n3qhyoclfngmpp277y4t4qwc4vswoo@5os4o5lumidn>
On Thu, May 7, 2026 at 11:55 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Mon, Apr 27, 2026 at 11:15:33AM +0200, Bartosz Golaszewski wrote:
> > This missed the v7.1 cycle so let's try to get it in for v7.2.
> >
> > Merging strategy: there are build-time dependencies between the crypto
> > and DMA patches so the best approach is for Vinod to create an immutable
> > branch with the DMA part pulled in by the crypto tree.
> >
> > This iteration continues to build on top of v12 but uses the BAM's NWD
> > bit on data descriptors as suggested by Stephan. To that end, there are
> > some more changes like reversing the order of command and data
> > descriptors queuedy by the QCE driver.
> >
> > Currently the QCE crypto driver accesses the crypto engine registers
> > directly via CPU. Trust Zone may perform crypto operations simultaneously
> > resulting in a race condition. To remedy that, let's introduce support
> > for BAM locking/unlocking to the driver. The BAM driver will now wrap
> > any existing issued descriptor chains with additional descriptors
> > performing the locking when the client starts the transaction
> > (dmaengine_issue_pending()). The client wanting to profit from locking
> > needs to switch to performing register I/O over DMA and communicate the
> > address to which to perform the dummy writes via a call to
> > dmaengine_desc_attach_metadata().
> >
> > In the specific case of the BAM DMA this translates to sending command
> > descriptors performing dummy writes with the relevant flags set. The BAM
> > will then lock all other pipes not related to the current pipe group, and
> > keep handling the current pipe only until it sees the the unlock bit.
> >
> > In order for the locking to work correctly, we also need to switch to
> > using DMA for all register I/O.
> >
> > On top of this, the series contains some additional tweaks and
> > refactoring.
> >
> > The goal of this is not to improve the performance but to prepare the
> > driver for supporting decryption into secure buffers in the future.
> >
> > Tested with tcrypt.ko, kcapi and cryptsetup.
> >
> > Shout out to Daniel and Udit from Qualcomm for helping me out with some
> > DMA issues we encountered.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> For the whole series,
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
>
> Thanks for incorporating all the comments, Bart!
>
> - Mani
>
Vinod: Can you please queue patches 1-5 on an immutable branch for
v7.2 and provide it to Herbert to queue the following crypto patches?
Thanks,
Bartosz
^ permalink raw reply
* Re: powernv_rng_read: Oops: Kernel access of bad area, sig: 11 [#1]
From: Paul Menzel @ 2026-05-11 7:00 UTC (permalink / raw)
To: Madhavan Srinivasan, Olivia Mackall, Herbert Xu, Michael Ellerman
Cc: linux-crypto, linuxppc-dev, LKML, Jason A. Donenfeld
In-Reply-To: <0c06bc14-9459-44d5-9e28-b0b78c0fbe36@linux.ibm.com>
[Cc: +Jason]
Dear Madhavan,
Am 07.05.26 um 04:40 schrieb Madhavan Srinivasan:
>
> On 5/6/26 7:31 PM, Paul Menzel wrote:
>> After a long while, on the 8335-GCA POWER8 (raw) 0x4d0200
>> opal:skiboot-5.4.8-5787ad3 PowerNV, I built Linux from Linus’ master
>> branch and rebooted via kexec.
>>
>> ```
>> [ 0.000000] Linux version 7.1.0-rc2+ (pmenzel@flughafenberlinbrandenburgwillybrandt.molgen.mpg.de) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #3 SMP PREEMPT Wed May 6 08:50:58 CEST 2026
>> […]
>> [ 17.901992] Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
>> [ 17.902011] BUG: Kernel NULL pointer dereference on read at 0x00000000
>> [ 17.902018] Faulting instruction address: 0xc0000000000e7138
>> [ 17.902027] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 17.902034] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>> [ 17.902045] Modules linked in: powernv_rng(+) bnx2x ofpart ibmpowernv bfq mdio cmdlinepart powernv_flash ipmi_powernv ipmi_devintf mtd ipmi_msghandler at24(+) vmx_crypto opal_prd sch_fq_codel nfsd parport_pc ppdev auth_rpcgss nfs_acl lp lockd grace parport sunrpc autofs4 btrfs xor libblake2b raid6_pq ast drm_shmem_helper drm_client_lib i2c_algo_bit drm_kms_helper drm ahci drm_panel_orientation_quirks libahci
>> [ 17.902185] CPU: 147 UID: 0 PID: 2626 Comm: hwrng Not tainted 7.1.0-rc2+ #3 PREEMPTLAZY
>> [ 17.902197] Hardware name: 8335-GCA POWER8 (raw) 0x4d0200 opal:skiboot-5.4.8-5787ad3 PowerNV
>> [ 17.902204] NIP: c0000000000e7138 LR: c00800001ec8013c CTR: c0000000000e70fc
>> [ 17.902212] REGS: c000000092913c50 TRAP: 0300 Not tainted (7.1.0-rc2+)
>> [ 17.902222] MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 44420220 XER: 20000000
>> [ 17.902269] CFAR: c00800001ec8026c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
>> GPR00: c00800001ec8013c c000000092913ef0 c000000001c18100 c00000002222d900
>> GPR04: c00000002222d900 0000000000000080 0000000000000001 0000000000000000
>> GPR08: 0000000000000000 c000000002212000 c0000000951e1780 c00800001ec80258
>> GPR12: c0000000000e70fc c00000ffff6fd700 c0000000001d11c0 c00000001b99b9c0
>> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> GPR24: 0000000000000000 c000000002fe6a58 0000000000000000 0000000000000000
>> GPR28: c000000002fe6a20 0000000000000010 000000000000000f c00000002222d900
>> [ 17.902406] NIP [c0000000000e7138] pnv_get_random_long+0x3c/0x114
>> [ 17.902426] LR [c00800001ec8013c] powernv_rng_read+0x78/0xc4 [powernv_rng]
>> [ 17.902444] Call Trace:
>> [ 17.902448] [c000000092913ef0] [c000000092913f30] 0xc000000092913f30 (unreliable)
>> [ 17.902463] [c000000092913f30] [c000000000decd58] hwrng_fillfn+0xd4/0x3dc
>> [ 17.902484] [c000000092913f90] [c0000000001d1328] kthread+0x170/0x1a4
>> [ 17.902498] [c000000092913fe0] [c00000000000d030] start_kernel_thread+0x14/0x18
>> [ 17.902513] Code: 60000000 7d2000a6 71290010 418200bc e94d0908 812a0000 39290001 912a0000 e90d0030 3d220060 39299f00 7d08482a <e9280000> 7c0004ac e8e90000 0c070000
>> [ 17.902569] ---[ end trace 0000000000000000 ]---
>> [ 18.008801] pstore: backend (nvram) writing error (-1)
>>
>> [ 18.015458] note: hwrng[2626] exited with irqs disabled
>> [ 18.015483] note: hwrng[2626] exited with preempt_count 1
>> ```
>>
>> Please find the output of `dmesg` attached.
>
> This is from my yesterday's boot test log in my P8, did not see this fail.
>
> root@ltcppm1:~# uname -a
> Linux ltcppm1.ltc.tadn.ibm.com 7.1.0-rc2-00021-gf583bd5f64d4 #1 SMP PREEMPT Wed May 6 00:55:45 EDT 2026 ppc64le GNU/Linux
> root@ltcppm1:~# dmesg
> [ 0.000000] [ T0] random: crng init done
> [ 0.000000] [ T0] hash-mmu: Page sizes from device-tree:
> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=12, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=0
> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=16, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=7
> [ 0.000000] [ T0] hash-mmu: base_shift=12: shift=24, sllp=0x0000, avpnm=0x00000000, tlbiel=1, penc=56
> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=16, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=1
> [ 0.000000] [ T0] hash-mmu: base_shift=16: shift=24, sllp=0x0110, avpnm=0x00000000, tlbiel=1, penc=8
> [ 0.000000] [ T0] hash-mmu: base_shift=24: shift=24, sllp=0x0100, avpnm=0x00000001, tlbiel=0, penc=0
> [ 0.000000] [ T0] hash-mmu: base_shift=34: shift=34, sllp=0x0120, avpnm=0x000007ff, tlbiel=0, penc=3
> [ 0.000000] [ T0] Enabling pkeys with max key count 32
> [ 0.000000] [ T0] Activating Kernel Userspace Access Prevention
> [ 0.000000] [ T0] Activating Kernel Userspace Execution Prevention
> [ 0.000000] [ T0] hash-mmu: Page orders: linear mapping = 24, virtual = 16, io = 16, vmemmap = 24
> [ 0.000000] [ T0] hash-mmu: Using 1TB segments
> [ 0.000000] [ T0] hash-mmu: Initializing hash mmu with SLB
> [ 0.000000] [ T0] Linux version 7.1.0-rc2-00021-gf583bd5f64d4
> (root@ltcppm1.ltc.tadn.ibm.com) (gcc (GCC) 16.1.1 20260501 (Red Hat 16.1.1-1), GNU ld version 2.46-1.fc44) #1 SMP PREEMPT Wed May 6 00:55:45 EDT 2026
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000039c00000..0x000000003b6801ff (27136 KiB) map non-reusable ibm,firmware-allocs-memory@39c00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000800000000..0x0000000800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@800000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001000000000..0x0000001000dc01ff (14080 KiB) map non-reusable ibm,firmware-allocs-memory@1000000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001800000000..0x0000001800e801ff (14848 KiB) map non-reusable ibm,firmware-allocs-memory@1800000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030000000..0x00000000302fffff (3072 KiB) map non-reusable ibm,firmware-code@30000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031000000..0x0000000031bfffff (12288 KiB) map non-reusable ibm,firmware-data@31000000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000030300000..0x0000000030ffffff (13312 KiB) map non-reusable ibm,firmware-heap@30300000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000000031c00000..0x0000000033fdffff (36736 KiB) map non-reusable ibm,firmware-stacks@31c00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd510000..0x0000001ffd69ffff (1600 KiB) map non-reusable ibm,hbrt-code-image@1ffd510000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd6a0000..0x0000001ffd6fffff (384 KiB) map non-reusable ibm,hbrt-target-image@1ffd6a0000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffd700000..0x0000001ffd7fffff (1024 KiB) map non-reusable ibm,hbrt-vpd-image@1ffd700000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffda00000..0x0000001ffdafffff (1024 KiB) map non-reusable ibm,slw-image@1ffda00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffde00000..0x0000001ffdefffff (1024 KiB) map non-reusable ibm,slw-image@1ffde00000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe200000..0x0000001ffe2fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe200000
> [ 0.000000] [ T0] OF: reserved mem: 0x0000001ffe600000..0x0000001ffe6fffff (1024 KiB) map non-reusable ibm,slw-image@1ffe600000
> [ 0.000000] [ T0] Found initrd at 0xc000000006a40000:0xc00000000815ae9e
> [ 0.000000] [ T0] Hardware name: 8247-22L POWER8E (raw) 0x4b0201 opal:skiboot-v5.4.12 PowerNV
> [ 0.000000] [ T0] printk: legacy bootconsole [udbg0] enabled
> [ 0.000000] [ T0] CPU maps initialized for 8 threads per core
> [ 0.000000] [ T0] (thread shift is 3)But I my opal version 5.4.12.
>
> Thanks for reporting the issue, will have an look at it.
I bisected it to a change between 5.19-rc3 and 5.19-rc4, and merge
commit 8100775d59a6 (Merge tag 'powerpc-5.19-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) [1] indeed
has rng related changes
> - Three fixes to wire up our various RNGs earlier in boot so they're
> available for use in the initial seeding in random_init().
> [ 0.000000] [ T0] Allocated 4608 bytes for 160 pacas
> [ 0.000000] [ T0]
> -----------------------------------------------------
>
> .......
>
> [ 37.407674] [ T900] audit: type=1130 audit(1778043621.931:10): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=lvm2-monitor comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [ 37.413015] [ T900] audit: type=1130 audit(1778043621.937:11): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-sysctl comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [ 38.448156] [ T2286] powernv_rng: Registered powernv hwrng.
> [ 38.575227] [ T2264] tg3 0005:09:00.1 enP5p9s0f1: renamed from eth1
> [ 38.582176] [ T2223] tg3 0005:09:00.2 enP5p9s0f2: renamed from eth2
> ........
>
> ////cpuinfo output
>
> processor : 159
>
> cpu : POWER8E (raw), altivec supported
> clock : 2061.000000MHz
> revision : 2.1 (pvr 004b 0201)
>
> timebase : 512000000
> platform : PowerNV
> model : 8247-22L
> machine : PowerNV 8247-22L
> firmware : OPAL
> MMU : Hash
>
>
> But my system opal version 5.4.12.
> Thanks for reporting the issue, will have an look at it.
Thank you.
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8100775d59a6789c3c6c309de26fac52f129cba8
^ permalink raw reply
* Re: [PATCH] crypto: algif_aead - Prevent async UAF on early socket close
From: Herbert Xu @ 2026-05-11 5:32 UTC (permalink / raw)
To: yuri08; +Cc: davem, w, linux-crypto, linux-kernel
In-Reply-To: <CAFpG_BHU49CKUpak795wkiczROiKUX8CsN2dp_94s4P5M9rr4Q@mail.gmail.com>
On Sun, May 10, 2026 at 09:05:57PM +0700, yuri08 wrote:
> When an AEAD request falls back to the asynchronous software path (e.g.,
> cryptd), the Crypto API returns -EINPROGRESS and control returns to
> user-space. If user-space immediately closes the socket fd, the memory
> mapping for the RX SGL (req->dst) provided via recvmsg is torn down
> while the cryptd workqueue is still actively writing to it (e.g., during
> authenc_esn_decrypt ESN scratch writes).
>
> To mitigate this race condition without adding complex pinning mechanisms,
> we utilize the crypto backlog capability. By adding
> CRYPTO_TFM_REQ_MAY_BACKLOG to the async callback flags, we ensure that
> the crypto core properly serializes the request completion, preventing
> the socket resources from being released by af_alg_release() while the
> workqueue is still processing the destination buffers.
>
> Fixes: a664bf3d603d ("crypto: algif_aead - Revert to operating
> out-of-place")
> Signed-off-by: NGUYEN TUAN <nvt031@gmail.com>
> ---
> crypto/algif_aead.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index cb651ab58d62..123456789abcd 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -229,7 +229,8 @@ static int _aead_recvmsg(struct socket *sock, struct
> msghdr *msg,
> areq->outlen = outlen;
>
> aead_request_set_callback(&areq->cra_u.aead_req,
> - CRYPTO_TFM_REQ_MAY_SLEEP,
> + CRYPTO_TFM_REQ_MAY_SLEEP |
> + CRYPTO_TFM_REQ_MAY_BACKLOG,
This patch makes no sense. We got rid of MAY_BACKLOG back in 2020
specifically because it causes the kind of problems that you're
reporting.
On a modern kernel, the socket reference is meant to keep the socket
from releasing its data prematurely. The socket reference is only
dropped after completion.
Is it possible that you're using some ancient kernel dating from
the 2010's? Because from the context of the patch that you sent
in private, it appears to indicate that MAY_BACKLOG was still
being used.
Cheers,
--
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: [PATCH] crypto : ecc - Fix carry overflow in vli multiplication
From: Lukas Wunner @ 2026-05-11 5:30 UTC (permalink / raw)
To: Anastasia Tishchenko
Cc: Ignat Korchagin, Stefan Berger, Herbert Xu, David S . Miller,
linux-crypto, linux-kernel
In-Reply-To: <20260508114844.29694-1-sv3iry@gmail.com>
On Fri, May 08, 2026 at 02:48:44PM +0300, 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.
[...]
> +++ 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);
> + 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;
Thanks for spotting this.
crypto/ecc.c is derived from Ken MacKay's micro-ecc library and
that library has always had the check that you're adding here:
https://github.com/kmackay/micro-ecc/blob/master/uECC.c#L403
When commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
introduced crypto/ecc.c, it split the muladd() function in the
micro-ecc library into separate mul_64_64() and add_128_128() helpers.
The function names suggest that this was probably done to allow
moving them to include/linux/math64.h and/or lib/math/div64.c
in case they're needed elsewhere in the kernel later.
It seems the check got lost in translation.
However while your patch looks correct to me, I think the overflow
check isn't very obvious or readable. And I don't like how it leaks
outside the add_128_128() helper.
The kernel gained a check_add_overflow() helper relatively recently
in include/linux/overflow.h. What I'd prefer is if you could rename
add_128_128() to check_add_128_128_overflow() and let it return a bool
indicating whether an overflow occurred. Then r2 is simply incremented
if the return value is true. Optionally you could add a third parameter
for the result (like check_add_overflow() does), but that's not strictly
needed for the callers in crypto/ecc.c and would merely be in preparation
for reuse of the function by other code in the kernel.
Does that make sense?
Please add these tags if/when respinning:
Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
Cc: stable@vger.kernel.org # v4.8+
Personally I order tags according to Bjorn's preference:
https://lore.kernel.org/r/20171026223701.GA25649@bhelgaas-glaptop.roam.corp.google.com/
It would also be good if you could include the backstory I've outlined
above in the commit message so that it's recorded in the git history
and doesn't have to be dug out from mailing list archives.
Thanks!
Lukas
^ permalink raw reply
* Re: [PATCH] hwrng: tpm: Do not enable by default
From: James Bottomley @ 2026-05-11 3:31 UTC (permalink / raw)
To: Jan Kiszka, Jarkko Sakkinen, Niedermayr, BENEDIKT
Cc: 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: <2d00dd26-9190-4e25-bda2-b2ac9bcd5180@siemens.com>
On Sun, 2026-05-10 at 22:42 +0200, Jan Kiszka wrote:
> On 09.05.26 17:18, Jarkko Sakkinen wrote:
> > 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.
You keep quoting this to us, and other parts of the spec. However, you
forgot to quote from the Section 7 compliance statement in the same
spec which says:
the NV subsystem of the reference implementation is not
representative of the actual implementation of most physical NV
implementations but is a crude analog.
I get that the the optee people failed to realize this and only just
corrected the mistake, but the fact is that all other TPM
implementations, both physical and firmware don't have this wear
problem you've given yourselves because they noticed.
> > > 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.
Yours is the only one I've ever come across.
> > Really this would need a product and official bug bulletin for it
> > to even consider a workaround. Speculation does not count.
> >
>
> The key point Benedikt tries to make here is that the TPM 2 spec
> forces any vendor to do something about persisting the last seen time
> at least every 70 min. If they didn't do that, then they would
> violate the space
That's correct, but a red herring: if the optee TPM had done this 70
minute flush ab initio you wouldn't have the wear problem because the
seed writes would be much less frequent.
> - arguably a bug.
Well, not following the spec is a bug, yes, but it's not a bug in the
kernel ...
Regards,
James
^ permalink raw reply
* [PATCH] crypto: hisilicon/sec2 - lower priority for hisilicon crypto implementations
From: Chenghai Huang @ 2026-05-11 0:49 UTC (permalink / raw)
To: herbert, davem
Cc: linux-kernel, linux-crypto, fanghao11, liulongfang, qianweili,
wangzhou1
From: lizhi <lizhi206@huawei.com>
Lower the priority of HiSilicon's crypto implementations to allow more
suitable alternatives to be selected. For example, certain kernel
use-cases do not benefit from HiSilicon's symmetric crypto algorithms.
This change ensures that more appropriate options are chosen first while
retaining HiSilicon's implementations as alternatives.
Signed-off-by: lizhi <lizhi206@huawei.com>
Signed-off-by: Chenghai Huang <huangchenghai2@huawei.com>
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2471a4dd0b50..77e0e03cbcab 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -20,7 +20,7 @@
#include "sec.h"
#include "sec_crypto.h"
-#define SEC_PRIORITY 4001
+#define SEC_PRIORITY 80
#define SEC_XTS_MIN_KEY_SIZE (2 * AES_MIN_KEY_SIZE)
#define SEC_XTS_MID_KEY_SIZE (3 * AES_MIN_KEY_SIZE)
#define SEC_XTS_MAX_KEY_SIZE (2 * AES_MAX_KEY_SIZE)
--
2.33.0
^ permalink raw reply related
* Re: [PATCH] crypto: ctr - Convert from skcipher to lskcipher
From: Eric Biggers @ 2026-05-11 0:19 UTC (permalink / raw)
To: Alexandre Knecht
Cc: herbert, David S . Miller, linux-crypto, linux-kernel, bpf
In-Reply-To: <CAHAB8Wy1APeCcm7_OfrNYeZFcMXfZ5rUSeDX7-c7WO_rGg2Zig@mail.gmail.com>
On Mon, May 11, 2026 at 02:02:22AM +0200, Alexandre Knecht wrote:
> Le lun. 11 mai 2026 à 01:44, Eric Biggers <ebiggers@kernel.org> a écrit :
> > Also note that lskcipher doesn't provide access to the accelerated AES
> > mode implementations. Indeed, almost nothing is supported by lskcipher.
> > The fact that you found something to be missing isn't surprising.
> >
> > I think "lskcipher" is kind of a dead end, to be honest. It's not clear
> > why it got added. The path forwards is to get the AES encryption modes
> > added to lib/crypto/ and to just use that instead.
> >
> > - Eric
>
> Hi Eric,
>
> Thanks for the review — you're asking the right questions.
>
> I'm developing a VXLAN/EVPN-based CNI for Kubernetes (releasing in the
> coming months), and the goal is to implement datapath encryption for
> overlay traffic in a zero-trust datacenter model. The encryption
> happens in BPF programs attached via TC on the VXLAN device (encrypt
> inner frames on egress, decrypt on ingress).
>
> The algorithm I actually need is AES-GCM (authenticated encryption of
> VXLAN inner frames, with the outer headers as AAD). When I looked at
> bpf_crypto, I found that:
>
> 1. Only lskcipher ("skcipher" type) was implemented
> 2. ecb(aes) was the only usable algorithm
> 3. AEAD support was designed for (authsize field exists in
> bpf_crypto_params, setauthsize in bpf_crypto_type) but never
> implemented
> 4. ctr(aes) wasn't available as lskcipher either
>
> I looked at Herbert's history converting ECB and CBC to lskcipher and
> assumed that was the path forward for CTR. But you're right, the
> real goal is AEAD, not CTR. CTR alone doesn't give me integrity.
>
> Your point about lib/crypto/ is interesting. If there's a path to
> expose AES-GCM (or the building blocks) as direct library calls that
> BPF programs in TC/XDP could use (avoiding the template/instance
> machinery and getting hardware acceleration) that would be ideal for
> this use case.
>
> What would that look like? Is there existing lib/crypto/ work for
> AES-GCM that could be wired up to BPF, or would that need to be
> built?
Sure, it makes sense that AES-GCM is what you actually need. There's
actually a lot of demand for AES-GCM in lib/crypto/, and I've been
working on it.
There's already an existing AES-GCM lib/crypto/ API (see
include/crypto/gcm.h), and I optimized it a bit in 7.0 and 7.1. For
example, it now uses the architecture-optimized single-block AES code.
You might be able to go ahead and use that right now.
However, it currently supports only one-shot computation, and it doesn't
yet take advantage of the fully optimized AES-GCM assembly code that
interleaves the AES and GHASH computations. I'm planning to address
both of those limitations soon.
Anyway, that seems like the clear way forward. The lskcipher thing
seems like a dead end to me.
- Eric
^ permalink raw reply
* Re: [PATCH] crypto: ctr - Convert from skcipher to lskcipher
From: Alexandre Knecht @ 2026-05-11 0:02 UTC (permalink / raw)
To: Eric Biggers; +Cc: herbert, David S . Miller, linux-crypto, linux-kernel, bpf
In-Reply-To: <20260510234452.GB60510@quark>
Le lun. 11 mai 2026 à 01:44, Eric Biggers <ebiggers@kernel.org> a écrit :
> Also note that lskcipher doesn't provide access to the accelerated AES
> mode implementations. Indeed, almost nothing is supported by lskcipher.
> The fact that you found something to be missing isn't surprising.
>
> I think "lskcipher" is kind of a dead end, to be honest. It's not clear
> why it got added. The path forwards is to get the AES encryption modes
> added to lib/crypto/ and to just use that instead.
>
> - Eric
Hi Eric,
Thanks for the review — you're asking the right questions.
I'm developing a VXLAN/EVPN-based CNI for Kubernetes (releasing in the
coming months), and the goal is to implement datapath encryption for
overlay traffic in a zero-trust datacenter model. The encryption
happens in BPF programs attached via TC on the VXLAN device (encrypt
inner frames on egress, decrypt on ingress).
The algorithm I actually need is AES-GCM (authenticated encryption of
VXLAN inner frames, with the outer headers as AAD). When I looked at
bpf_crypto, I found that:
1. Only lskcipher ("skcipher" type) was implemented
2. ecb(aes) was the only usable algorithm
3. AEAD support was designed for (authsize field exists in
bpf_crypto_params, setauthsize in bpf_crypto_type) but never
implemented
4. ctr(aes) wasn't available as lskcipher either
I looked at Herbert's history converting ECB and CBC to lskcipher and
assumed that was the path forward for CTR. But you're right, the
real goal is AEAD, not CTR. CTR alone doesn't give me integrity.
Your point about lib/crypto/ is interesting. If there's a path to
expose AES-GCM (or the building blocks) as direct library calls that
BPF programs in TC/XDP could use (avoiding the template/instance
machinery and getting hardware acceleration) that would be ideal for
this use case.
What would that look like? Is there existing lib/crypto/ work for
AES-GCM that could be wired up to BPF, or would that need to be
built?
Thanks,
Alexandre
^ permalink raw reply
* Re: [PATCH] crypto: ctr - Convert from skcipher to lskcipher
From: Eric Biggers @ 2026-05-10 23:44 UTC (permalink / raw)
To: Alexandre Knecht
Cc: herbert, David S . Miller, linux-crypto, linux-kernel, bpf
In-Reply-To: <20260510233237.GA60510@quark>
On Sun, May 10, 2026 at 04:32:39PM -0700, Eric Biggers wrote:
> On Mon, May 11, 2026 at 01:09:01AM +0200, Alexandre Knecht wrote:
> > Replace the existing skcipher CTR template with an lskcipher version,
> > following the pattern established by the CBC conversion (705b52fef3c7).
> >
> > This enables BPF programs using the bpf_crypto kfuncs to use CTR mode
> > ciphers like ctr(aes), which previously failed because
> > crypto_alloc_lskcipher() could not find an lskcipher implementation.
> > ECB and CBC already have lskcipher support; CTR was the missing piece.
> >
> > The rfc3686 template remains as an skcipher and continues to work
> > through the automatic lskcipher-to-skcipher bridge.
> >
> > Tested with NIST SP 800-38A test vectors (AES-128/192/256-CTR),
> > partial block handling, and rfc3686 compatibility. Kernel self-tests
> > pass on instantiation (selftest: passed in /proc/crypto).
> >
> > Signed-off-by: Alexandre Knecht <knecht.alexandre@gmail.com>
> > Assisted-by: Claude:claude-opus-4-6 checkpatch
>
> I'm confused. Why was that BPF crypto feature even added with ECB mode
> as the only supported encryption mode? Who is using that, and why?
>
> CTR isn't necessarily much better, either.
>
> What is the use case for the BPF crypto? The first step should be to
> decide what *specific* algorithm(s) it needs. It doesn't seem like that
> has ever happened, and I'm not sure this patch helps much.
>
> That needs to be done anyway. But that would also be helpful for a
> potential future switch to lib/crypto/, which would avoid all the weird
> issues with lskcipher etc.
Also note that lskcipher doesn't provide access to the accelerated AES
mode implementations. Indeed, almost nothing is supported by lskcipher.
The fact that you found something to be missing isn't surprising.
I think "lskcipher" is kind of a dead end, to be honest. It's not clear
why it got added. The path forwards is to get the AES encryption modes
added to lib/crypto/ and to just use that instead.
- Eric
^ permalink raw reply
* Re: [PATCH] crypto: ctr - Convert from skcipher to lskcipher
From: Eric Biggers @ 2026-05-10 23:32 UTC (permalink / raw)
To: Alexandre Knecht
Cc: herbert, David S . Miller, linux-crypto, linux-kernel, bpf
In-Reply-To: <20260510230901.1772949-1-knecht.alexandre@gmail.com>
On Mon, May 11, 2026 at 01:09:01AM +0200, Alexandre Knecht wrote:
> Replace the existing skcipher CTR template with an lskcipher version,
> following the pattern established by the CBC conversion (705b52fef3c7).
>
> This enables BPF programs using the bpf_crypto kfuncs to use CTR mode
> ciphers like ctr(aes), which previously failed because
> crypto_alloc_lskcipher() could not find an lskcipher implementation.
> ECB and CBC already have lskcipher support; CTR was the missing piece.
>
> The rfc3686 template remains as an skcipher and continues to work
> through the automatic lskcipher-to-skcipher bridge.
>
> Tested with NIST SP 800-38A test vectors (AES-128/192/256-CTR),
> partial block handling, and rfc3686 compatibility. Kernel self-tests
> pass on instantiation (selftest: passed in /proc/crypto).
>
> Signed-off-by: Alexandre Knecht <knecht.alexandre@gmail.com>
> Assisted-by: Claude:claude-opus-4-6 checkpatch
I'm confused. Why was that BPF crypto feature even added with ECB mode
as the only supported encryption mode? Who is using that, and why?
CTR isn't necessarily much better, either.
What is the use case for the BPF crypto? The first step should be to
decide what *specific* algorithm(s) it needs. It doesn't seem like that
has ever happened, and I'm not sure this patch helps much.
That needs to be done anyway. But that would also be helpful for a
potential future switch to lib/crypto/, which would avoid all the weird
issues with lskcipher etc.
- Eric
^ permalink raw reply
* [PATCH v2] crypto: krb5 - filter out async aead implementations at alloc
From: Michael Bommarito @ 2026-05-10 23:24 UTC (permalink / raw)
To: Herbert Xu, David Howells, David S. Miller, linux-crypto
Cc: Eric Biggers, Marc Dionne, linux-afs, Ilya Dryomov, Xiubo Li,
ceph-devel, stable, linux-kernel
In-Reply-To: <20260502132506.1936358-1-michael.bommarito@gmail.com>
krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and
rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL
completion callback and treat any negative return from
crypto_aead_{encrypt,decrypt}() as terminal, falling through to
kfree_sensitive(buffer). When the encrypt_name resolves to an
async AEAD instance the request returns -EINPROGRESS, the buffer
is freed while the backend's worker still holds a pointer, and the
worker dereferences the freed slab on completion.
KASAN report under UML+SLUB with a synthetic async aead backend
bound to krb5->encrypt_name:
BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7
The helpers were written synchronously, so filter the async
instances out at allocation time instead of plumbing
crypto_wait_req() through every call site.
Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and
net/ceph/crypto.c on systems with an async AEAD provider bound to
the krb5 enctype name.
Fixes: 00244da40f78 ("crypto/krb5: Implement the Kerberos5 rfc3961 encrypt and decrypt functions")
Fixes: 6c3c0e86c2ac ("crypto/krb5: Implement the AES enctypes from rfc8009")
Cc: stable@vger.kernel.org
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
crypto/krb5/krb5_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/krb5/krb5_api.c b/crypto/krb5/krb5_api.c
index 23026d4206c8..2b20284fa0ab 100644
--- a/crypto/krb5/krb5_api.c
+++ b/crypto/krb5/krb5_api.c
@@ -165,7 +165,7 @@ struct crypto_aead *krb5_prepare_encryption(const struct krb5_enctype *krb5,
struct crypto_aead *ci = NULL;
int ret = -ENOMEM;
- ci = crypto_alloc_aead(krb5->encrypt_name, 0, 0);
+ ci = crypto_alloc_aead(krb5->encrypt_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(ci)) {
ret = PTR_ERR(ci);
if (ret == -ENOENT)
--
2.53.0
^ permalink raw reply related
* [PATCH] crypto: ctr - Convert from skcipher to lskcipher
From: Alexandre Knecht @ 2026-05-10 23:09 UTC (permalink / raw)
To: herbert, David S . Miller
Cc: ebiggers, linux-crypto, linux-kernel, bpf, Alexandre Knecht
Replace the existing skcipher CTR template with an lskcipher version,
following the pattern established by the CBC conversion (705b52fef3c7).
This enables BPF programs using the bpf_crypto kfuncs to use CTR mode
ciphers like ctr(aes), which previously failed because
crypto_alloc_lskcipher() could not find an lskcipher implementation.
ECB and CBC already have lskcipher support; CTR was the missing piece.
The rfc3686 template remains as an skcipher and continues to work
through the automatic lskcipher-to-skcipher bridge.
Tested with NIST SP 800-38A test vectors (AES-128/192/256-CTR),
partial block handling, and rfc3686 compatibility. Kernel self-tests
pass on instantiation (selftest: passed in /proc/crypto).
Signed-off-by: Alexandre Knecht <knecht.alexandre@gmail.com>
Assisted-by: Claude:claude-opus-4-6 checkpatch
---
crypto/ctr.c | 143 +++++++++++++++++++--------------------------------
1 file changed, 54 insertions(+), 89 deletions(-)
diff --git a/crypto/ctr.c b/crypto/ctr.c
index a388f0ceb3a0..5fceaf47bedc 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -7,7 +7,6 @@
#include <crypto/algapi.h>
#include <crypto/ctr.h>
-#include <crypto/internal/cipher.h>
#include <crypto/internal/skcipher.h>
#include <linux/err.h>
#include <linux/init.h>
@@ -25,139 +24,105 @@ struct crypto_rfc3686_req_ctx {
struct skcipher_request subreq CRYPTO_MINALIGN_ATTR;
};
-static void crypto_ctr_crypt_final(struct skcipher_walk *walk,
- struct crypto_cipher *tfm)
+static int crypto_ctr_crypt_segment(struct crypto_lskcipher *cipher,
+ const u8 *src, u8 *dst, unsigned int nbytes,
+ u8 *iv)
{
- unsigned int bsize = crypto_cipher_blocksize(tfm);
- unsigned long alignmask = crypto_cipher_alignmask(tfm);
- u8 *ctrblk = walk->iv;
- u8 tmp[MAX_CIPHER_BLOCKSIZE + MAX_CIPHER_ALIGNMASK];
- u8 *keystream = PTR_ALIGN(tmp + 0, alignmask + 1);
- const u8 *src = walk->src.virt.addr;
- u8 *dst = walk->dst.virt.addr;
- unsigned int nbytes = walk->nbytes;
-
- crypto_cipher_encrypt_one(tfm, keystream, ctrblk);
- crypto_xor_cpy(dst, keystream, src, nbytes);
-
- crypto_inc(ctrblk, bsize);
-}
+ unsigned int bsize = crypto_lskcipher_blocksize(cipher);
-static int crypto_ctr_crypt_segment(struct skcipher_walk *walk,
- struct crypto_cipher *tfm)
-{
- void (*fn)(struct crypto_tfm *, u8 *, const u8 *) =
- crypto_cipher_alg(tfm)->cia_encrypt;
- unsigned int bsize = crypto_cipher_blocksize(tfm);
- u8 *ctrblk = walk->iv;
- const u8 *src = walk->src.virt.addr;
- u8 *dst = walk->dst.virt.addr;
- unsigned int nbytes = walk->nbytes;
-
- do {
- /* create keystream */
- fn(crypto_cipher_tfm(tfm), dst, ctrblk);
+ while (nbytes >= bsize) {
+ /* Encrypt counter block to produce keystream */
+ crypto_lskcipher_encrypt(cipher, iv, dst, bsize, NULL);
crypto_xor(dst, src, bsize);
-
- /* increment counter in counterblock */
- crypto_inc(ctrblk, bsize);
+ crypto_inc(iv, bsize); /* Increment counter */
src += bsize;
dst += bsize;
- } while ((nbytes -= bsize) >= bsize);
+ nbytes -= bsize;
+ }
return nbytes;
}
-static int crypto_ctr_crypt_inplace(struct skcipher_walk *walk,
- struct crypto_cipher *tfm)
+static int crypto_ctr_crypt_inplace(struct crypto_lskcipher *cipher,
+ u8 *dst, unsigned int nbytes, u8 *iv)
{
- void (*fn)(struct crypto_tfm *, u8 *, const u8 *) =
- crypto_cipher_alg(tfm)->cia_encrypt;
- unsigned int bsize = crypto_cipher_blocksize(tfm);
- unsigned long alignmask = crypto_cipher_alignmask(tfm);
- unsigned int nbytes = walk->nbytes;
- u8 *dst = walk->dst.virt.addr;
- u8 *ctrblk = walk->iv;
- u8 tmp[MAX_CIPHER_BLOCKSIZE + MAX_CIPHER_ALIGNMASK];
- u8 *keystream = PTR_ALIGN(tmp + 0, alignmask + 1);
-
- do {
- /* create keystream */
- fn(crypto_cipher_tfm(tfm), keystream, ctrblk);
- crypto_xor(dst, keystream, bsize);
+ unsigned int bsize = crypto_lskcipher_blocksize(cipher);
+ u8 keystream[MAX_CIPHER_BLOCKSIZE];
- /* increment counter in counterblock */
- crypto_inc(ctrblk, bsize);
+ while (nbytes >= bsize) {
+ /* Encrypt counter block to produce keystream */
+ crypto_lskcipher_encrypt(cipher, iv, keystream, bsize, NULL);
+ crypto_xor(dst, keystream, bsize);
+ crypto_inc(iv, bsize); /* Increment counter */
dst += bsize;
- } while ((nbytes -= bsize) >= bsize);
+ nbytes -= bsize;
+ }
+ memzero_explicit(keystream, sizeof(keystream));
return nbytes;
}
-static int crypto_ctr_crypt(struct skcipher_request *req)
+static int crypto_ctr_crypt(struct crypto_lskcipher *tfm, const u8 *src,
+ u8 *dst, unsigned int len, u8 *iv, u32 flags)
{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct crypto_cipher *cipher = skcipher_cipher_simple(tfm);
- const unsigned int bsize = crypto_cipher_blocksize(cipher);
- struct skcipher_walk walk;
+ struct crypto_lskcipher **ctx = crypto_lskcipher_ctx(tfm);
+ struct crypto_lskcipher *cipher = *ctx;
+ unsigned int bsize = crypto_lskcipher_blocksize(cipher);
+ bool final = flags & CRYPTO_LSKCIPHER_FLAG_FINAL;
unsigned int nbytes;
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
- while (walk.nbytes >= bsize) {
- if (walk.src.virt.addr == walk.dst.virt.addr)
- nbytes = crypto_ctr_crypt_inplace(&walk, cipher);
- else
- nbytes = crypto_ctr_crypt_segment(&walk, cipher);
-
- err = skcipher_walk_done(&walk, nbytes);
- }
-
- if (walk.nbytes) {
- crypto_ctr_crypt_final(&walk, cipher);
- err = skcipher_walk_done(&walk, 0);
+ if (src == dst)
+ nbytes = crypto_ctr_crypt_inplace(cipher, dst, len, iv);
+ else
+ nbytes = crypto_ctr_crypt_segment(cipher, src, dst, len, iv);
+
+ /* Handle final partial block. */
+ if (nbytes && final) {
+ u8 keystream[MAX_CIPHER_BLOCKSIZE];
+
+ crypto_lskcipher_encrypt(cipher, iv, keystream, bsize, NULL);
+ crypto_xor_cpy(dst + len - nbytes, src + len - nbytes,
+ keystream, nbytes);
+ crypto_inc(iv, bsize);
+ memzero_explicit(keystream, sizeof(keystream));
+ nbytes = 0;
}
- return err;
+ return nbytes;
}
static int crypto_ctr_create(struct crypto_template *tmpl, struct rtattr **tb)
{
- struct skcipher_instance *inst;
- struct crypto_alg *alg;
+ struct lskcipher_instance *inst;
int err;
- inst = skcipher_alloc_instance_simple(tmpl, tb);
+ inst = lskcipher_alloc_instance_simple(tmpl, tb);
if (IS_ERR(inst))
return PTR_ERR(inst);
- alg = skcipher_ialg_simple(inst);
-
/* Block size must be >= 4 bytes. */
err = -EINVAL;
- if (alg->cra_blocksize < 4)
+ if (inst->alg.co.base.cra_blocksize < 4)
goto out_free_inst;
/* If this is false we'd fail the alignment of crypto_inc. */
- if (alg->cra_blocksize % 4)
+ if (inst->alg.co.base.cra_blocksize % 4)
goto out_free_inst;
- /* CTR mode is a stream cipher. */
- inst->alg.base.cra_blocksize = 1;
-
/*
- * To simplify the implementation, configure the skcipher walk to only
- * give a partial block at the very end, never earlier.
+ * CTR mode is a stream cipher. Set chunksize to the underlying
+ * cipher block size so partial blocks only occur at the end.
*/
- inst->alg.chunksize = alg->cra_blocksize;
+ inst->alg.co.chunksize = inst->alg.co.base.cra_blocksize;
+ inst->alg.co.base.cra_blocksize = 1;
+ /* CTR encrypt and decrypt are the same XOR-based operation. */
inst->alg.encrypt = crypto_ctr_crypt;
inst->alg.decrypt = crypto_ctr_crypt;
- err = skcipher_register_instance(tmpl, inst);
+ err = lskcipher_register_instance(tmpl, inst);
if (err) {
out_free_inst:
inst->free(inst);
--
2.51.1
^ permalink raw reply related
* Re: [PATCH] hwrng: tpm: Do not enable by default
From: Jan Kiszka @ 2026-05-10 20:42 UTC (permalink / raw)
To: Jarkko Sakkinen, Niedermayr, BENEDIKT
Cc: 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: <af9QQah4QN5VD-4P@kernel.org>
On 09.05.26 17:18, Jarkko Sakkinen wrote:
> 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.
>
The key point Benedikt tries to make here is that the TPM 2 spec forces
any vendor to do something about persisting the last seen time at least
every 70 min. If they didn't do that, then they would violate the space
- arguably a bug. But, correct, it does not tell us anything about how
this happens in a random firmware TPM implementation.
>>
>> 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.
I would still not recommend anyone relying on a firmware TPM to turn on
CONFIG_HW_RANDOM_TPM if there are viable alternatives. In case of the
open source stack with optee_os + optee_ftpm, we know that at least one
exists: CONFIG_HW_RANDOM_OPTEE.
So, if there is no good place to document this in the kernel, maybe it
is worth to document it in optee_ftpm instead.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Andy Lutomirski @ 2026-05-10 18:06 UTC (permalink / raw)
To: Eric Biggers
Cc: Kamran Khan, Jeff Barnes, 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: <20260510163204.GA2279@sol>
On Sun, May 10, 2026 at 9:33 AM Eric Biggers <ebiggers@kernel.org> wrote:
> In any case, any hypothetical security benefit provided by AF_ALG would
> have to be *very high* to outweigh the continuous stream of
> vulnerabilities in it. I understand that people using AF_ALG might not
> be familiar with that continuous stream of vulnerabilities, but it would
> be worth spending some time researching what has been going on.
It would not be completely crazy to have a simple, straightforward
interface by which user code could ask the kernel to do a
cryptographic operation. Think:
int compute_keyed_hash(int key_fd, const void *data, size_t len);
where key_fd encodes both the key and the hash type (HMAC-SHA256 or
whatever), and there is a very, very small menu of hashes to choose
from.
But this is not really obviously worth the hassle. And AF_ALG is
definitely not the right interface.
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Eric Biggers @ 2026-05-10 16:32 UTC (permalink / raw)
To: Kamran Khan
Cc: Jeff Barnes, Andy Lutomirski, 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: <0b8bba44-f6bb-4d69-b9d4-5787c276d41a@inspirated.com>
On Sun, May 10, 2026 at 08:54:07AM -0700, Kamran Khan wrote:
> 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.
Note that if that memory-safety vulnerability leads to code execution in
the application, then it doesn't matter that it "only" has oracle
access. It can still decrypt any data encrypted by that key.
The relevant threat model would be arbitrary reads, not any
"memory-safety vulnerability".
> 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.
The standard solution is simply to use an isolated userspace process
like ssh-agent. Yes, the keys will be in "user memory". But "not
exposed in user memory" is *not* a correct statement of the problem.
(Also note that protecting not-actively-in-use data from arbitrary read
primitives doesn't require cryptography at all. That can be done simply
by using mprotect() to remove read permission from the memory, then
temporarily adding it back when it needs to be accessed.)
In any case, any hypothetical security benefit provided by AF_ALG would
have to be *very high* to outweigh the continuous stream of
vulnerabilities in it. I understand that people using AF_ALG might not
be familiar with that continuous stream of vulnerabilities, but it would
be worth spending some time researching what has been going on.
- Eric
^ permalink raw reply
* 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
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