kernel/linux.git/drivers/crypto/qat, branch v6.1.168

crypto: qat - fix warning on adf_pfvf_pf_proto.c

2026-03-04T12:19:26+00:00

[ Upstream commit 994689b8f91b02fdb5f64cba2412cde5ef3084b5 ] Building the QAT driver with -Wmaybe-uninitialized triggers warnings in qat_common/adf_pfvf_pf_proto.c. Specifically, the variables blk_type, blk_byte, and byte_max may be used uninitialized in handle_blkmsg_req(): make M=drivers/crypto/intel/qat W=1 C=2 "KCFLAGS=-Werror" \ KBUILD_CFLAGS_KERNEL=-Wmaybe-uninitialized \ CFLAGS_MODULE=-Wmaybe-uninitialized ... warning: ‘byte_max’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_type’ may be used uninitialized [-Wmaybe-uninitialized] warning: ‘blk_byte’ may be used uninitialized [-Wmaybe-uninitialized] Although the caller of handle_blkmsg_req() always provides a req.type that is handled by the switch, the compiler cannot guarantee this. Add a default case to the switch statement to handle an invalid req.type. Fixes: 673184a2a58f ("crypto: qat - introduce support for PFVF block messages") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: qat - flush misc workqueue during device shutdown

2026-02-06T15:44:23+00:00

[ Upstream commit 3d4df408ba9bad2b205c7fb8afc1836a6a4ca88a ] Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded. Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability. Fixes: e5745f34113b ("crypto: qat - enable power management for QAT GEN4") Signed-off-by: Giovanni Cabiddu Cc: stable@vger.kernel.org Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu [ Intel crypto drivers was moved by a4b16dad4657 ("crypto: qat - Move driver to drivers/crypto/intel/qat") so apply the patch to files under drivers/crypto/qat/qat_common in 6.1.y. ] Signed-off-by: Wenshan Lan Signed-off-by: Greg Kroah-Hartman

crypto: qat - fix ring to service map for QAT GEN4

2025-08-28T14:26:12+00:00

commit a238487f7965d102794ed9f8aff0b667cd2ae886 upstream. The 4xxx drivers hardcode the ring to service mapping. However, when additional configurations where added to the driver, the mappings were not updated. This implies that an incorrect mapping might be reported through pfvf for certain configurations. Add an algorithm that computes the correct ring to service mapping based on the firmware loaded on the device. Fixes: 0cec19c761e5 ("crypto: qat - add support for compression for 4xxx") Signed-off-by: Giovanni Cabiddu Reviewed-by: Damian Muszynski Reviewed-by: Tero Kristo Signed-off-by: Herbert Xu [Giovanni: backport to 6.1.y, conflict resolved simplifying the logic in the function get_ring_to_svc_map() as the QAT driver in v6.1 supports only limited configurations (crypto only and compression). Differs from upstream as the ring to service mapping is hardcoded rather than being dynamically computed.] Reviewed-by: Ahsan Atta Tested-by: Ahsan Atta Signed-off-by: Giovanni Cabiddu Signed-off-by: Greg Kroah-Hartman

crypto: qat - fix seq_file position update in adf_ring_next()

2025-08-15T10:05:04+00:00

[ Upstream commit 6908c5f4f066a0412c3d9a6f543a09fa7d87824b ] The `adf_ring_next()` function in the QAT debug transport interface fails to correctly update the position index when reaching the end of the ring elements. This triggers the following kernel warning when reading ring files, such as /sys/kernel/debug/qat_c6xx_/transport/bank_00/ring_00: [27725.022965] seq_file: buggy .next function adf_ring_next [intel_qat] did not update position index Ensure that the `*pos` index is incremented before returning NULL when after the last element in the ring is found, satisfying the seq_file API requirements and preventing the warning. Fixes: a672a9dc872e ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Giovanni Cabiddu Reviewed-by: Ahsan Atta Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: qat - remove faulty arbiter config reset

2024-12-14T18:53:17+00:00

[ Upstream commit 70199359902f1c7187dcb28a1be679a7081de7cc ] Resetting the service arbiter config can cause potential issues related to response ordering and ring flow control check in the event of AER or device hang. This is because it results in changing the default response ring size from 32 bytes to 16 bytes. The service arbiter config reset also disables response ring flow control check. Thus, by removing this reset we can prevent the service arbiter from being configured inappropriately, which leads to undesired device behaviour in the event of errors. Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator") Signed-off-by: Ahsan Atta Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: qat - fix unintentional re-enabling of error interrupts

2024-09-12T09:10:23+00:00

[ Upstream commit f0622894c59458fceb33c4197462bc2006f3fc6b ] The logic that detects pending VF2PF interrupts unintentionally clears the section of the error mask register(s) not related to VF2PF. This might cause interrupts unrelated to VF2PF, reported through errsou3 and errsou5, to be reported again after the execution of the function disable_pending_vf2pf_interrupts() in dh895xcc and GEN2 devices. Fix by updating only section of errmsk3 and errmsk5 related to VF2PF. Signed-off-by: Hareshx Sankar Raj Reviewed-by: Damian Muszynski Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: qat - extend scope of lock in adf_cfg_add_key_value_param()

2024-08-03T06:49:21+00:00

[ Upstream commit 6424da7d8b938fe66e7e771eaa949bc7b6c29c00 ] The function adf_cfg_add_key_value_param() attempts to access and modify the key value store of the driver without locking. Extend the scope of cfg->lock to avoid a potential race condition. Fixes: 92bf269fbfe9 ("crypto: qat - change behaviour of adf_cfg_add_key_value_param()") Signed-off-by: Nivas Varadharajan Mugunthakumar Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak

2024-06-16T11:41:38+00:00

commit d3b17c6d9dddc2db3670bc9be628b122416a3d26 upstream. Using completion_done to determine whether the caller has gone away only works after a complete call. Furthermore it's still possible that the caller has not yet called wait_for_completion, resulting in another potential UAF. Fix this by making the caller use cancel_work_sync and then freeing the memory safely. Fixes: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery") Cc: #6.8+ Signed-off-by: Herbert Xu Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: qat - resolve race condition during AER recovery

2024-04-03T13:19:26+00:00

[ Upstream commit 7d42e097607c4d246d99225bf2b195b6167a210c ] During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Cc: Signed-off-by: Damian Muszynski Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: qat - fix double free during reset

2024-04-03T13:19:26+00:00

[ Upstream commit 01aed663e6c421aeafc9c330bda630976b50a764 ] There is no need to free the reset_data structure if the recovery is unsuccessful and the reset is synchronous. The function adf_dev_aer_schedule_reset() handles the cleanup properly. Only asynchronous resets require such structure to be freed inside the reset worker. Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework") Signed-off-by: Svyatoslav Pankratov Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Stable-dep-of: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery") Signed-off-by: Sasha Levin