CVE-2023-54126 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
crypto: safexcel - Cleanup ring IRQ workqueues on load failure
A failure loading the safexcel driver results in the following warning on boot, because the IRQ affinity has not been correctly cleaned up. Ensure we clean up the affinity and workqueues on a failure to load the driver.
crypto-safexcel: probe of f2800000.crypto failed with error -2 ------------[ cut here ]------------
WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340 Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4 CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G W 6.1.6-00002-g9d4898824677 #3 Hardware name: MikroTik RB5009 (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : free_irq+0x300/0x340 lr : free_irq+0x2e0/0x340 sp : ffff800008fa3890 x29: ffff800008fa3890 x28: 0000000000000000 x27: 0000000000000000 x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50 x23: 0000000000000000 x22: 000000000000004a x21: ffff0000093e0d80 x20: ffff000009034c00 x19: ffff00000615fc00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 000075f5c1584c5e x14: 0000000000000017 x13: 0000000000000000 x12: 0000000000000040 x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370 x8 : ffff000000579dd0 x7 : 0000000000000000 x6 : ffff000000579e18 x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188 x2 : 0000000013033204 x1 : ffff000009034c00 x0 : ffff8000087eadf0 Call trace: free_irq+0x300/0x340 devm_irq_release+0x14/0x20 devres_release_all+0xa0/0x100 device_unbind_cleanup+0x14/0x60 really_probe+0x198/0x2d4 __driver_probe_device+0x74/0xdc driver_probe_device+0x3c/0x110 __driver_attach+0x8c/0x190 bus_for_each_dev+0x6c/0xc0 driver_attach+0x20/0x30 bus_add_driver+0x148/0x1fc driver_register+0x74/0x120 __platform_driver_register+0x24/0x30 safexcel_init+0x48/0x1000 [crypto_safexcel]
do_one_initcall+0x4c/0x1b0 do_init_module+0x44/0x1cc load_module+0x1724/0x1be4 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x1c/0x24 invoke_syscall+0x44/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x20/0x80 el0_svc+0x14/0x4c el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x148/0x14c ---[ end trace 0000000000000000 ]---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/03/2026
The vulnerability described in CVE-2023-54126 relates to improper resource cleanup within the Linux kernel's crypto-safexcel driver, specifically when the driver fails to load during system boot. This issue manifests as a warning message indicating that IRQ affinity has not been correctly cleaned up, which can lead to system instability and potential security implications. The problem occurs during the initialization phase of the safexcel cryptographic hardware accelerator driver, which is designed to provide hardware acceleration for cryptographic operations on certain embedded systems. When the driver probe fails with error code -2, indicating a generic failure such as resource allocation issues or hardware unavailability, the kernel does not properly release the associated IRQ workqueues and affinity settings, leading to resource leaks and potential conflicts.
The technical flaw stems from inadequate error handling in the driver's initialization sequence, where the cleanup routines for IRQ workqueues and affinity settings are not invoked upon load failure. This behavior aligns with CWE-459, which describes "Incomplete Cleanup," and specifically relates to improper resource management during driver initialization. The warning message originates from kernel/irq/manage.c in the free_irq function, indicating that the kernel attempted to free an IRQ that was either already freed or never properly allocated, suggesting a double-free scenario or improper resource state management. The call trace demonstrates that the error propagates through the device driver subsystem, with the cleanup process attempting to release IRQ resources via devm_irq_release, but failing due to incomplete cleanup of previously allocated resources.
The operational impact of this vulnerability extends beyond simple warning messages, potentially affecting system reliability and resource utilization in embedded environments where the safexcel driver is present. When the driver fails to initialize properly, the leftover IRQ workqueues and affinity settings can cause conflicts with subsequent driver loading attempts or system operations, leading to potential system hangs or resource exhaustion. This issue is particularly concerning in network equipment and embedded systems like the MikroTik RB5009 mentioned in the error output, where cryptographic acceleration is frequently utilized and system stability is critical. The vulnerability can be exploited by adversaries to cause denial-of-service conditions or to consume system resources, potentially leading to system instability or crashes in scenarios where multiple driver initialization attempts occur.
Mitigation strategies for this vulnerability involve ensuring proper error handling and resource cleanup in driver initialization routines. System administrators should update to kernel versions that include the fix for this issue, which typically involves modifying the safexcel driver to properly clean up IRQ workqueues and affinity settings regardless of initialization success or failure. The fix implements proper cleanup paths that ensure all allocated resources are released even when the driver fails to load, preventing the accumulation of stale IRQ workqueues that could lead to system instability. Additionally, monitoring systems should be configured to detect and alert on such warning messages, as they may indicate underlying hardware or driver compatibility issues that could lead to more serious problems. From an ATT&CK perspective, this vulnerability could be leveraged in initial access or persistence phases, where an attacker might exploit resource exhaustion or system instability to maintain access to the target system, though the primary concern remains system reliability and availability rather than direct privilege escalation.