CVE-2022-50171 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - don't sleep when in softirq
When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error:
BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2]
sec_process+0x28/0x1ac [hisi_sec2]
sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2]
sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2]
crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc]
crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv]
crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4]
esp_output+0x120/0x19c [esp4]
xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00?
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 02/03/2026
The vulnerability identified as CVE-2022-50171 affects the Linux kernel's cryptographic subsystem, specifically within the hisilicon/sec driver implementation. This issue manifests when the kunpeng920 encryption driver attempts to decrypt and encrypt packets during softirq execution contexts, creating a critical scheduling conflict that violates kernel atomic execution principles. The problem stems from an improper use of mutex locks within a softirq handler, which is strictly prohibited in kernel design to prevent deadlocks and system instability. The kernel's error message "BUG: scheduling while atomic: swapper/57/0/0x00000300" clearly indicates that the system attempted to perform a scheduling operation while in an atomic context, a scenario that fundamentally breaks kernel integrity and can lead to system crashes or data corruption.
The technical flaw occurs in the hisi_sec2 driver module where the sec_request_init function attempts to acquire a mutex lock during softirq processing, specifically within the crypto_skcipher_encrypt path. This sequence involves multiple kernel components including authenc, echainiv, esp4, xfrm, and tcp layers, demonstrating how the vulnerability propagates through the network stack when processing encrypted packets. The call trace reveals the path from TCP connection establishment through IP packet processing to the final cryptographic operation that triggers the mutex lock attempt. According to CWE-362, this represents a concurrency vulnerability where a single thread attempts to acquire a lock while already holding one, creating a potential deadlock scenario. The ATT&CK framework would classify this under T1059.001 for system call manipulation and T1566.001 for initial access through network protocols, as exploitation could allow for denial of service or potentially privilege escalation.
The operational impact of this vulnerability extends beyond simple system instability, as it can cause complete network service disruption when encrypted traffic flows are processed through affected systems. The softirq context is designed for high-performance, low-latency packet processing and must remain atomic to maintain system responsiveness. When mutex operations are attempted within this context, the kernel's scheduler becomes deadlocked, resulting in system hangs or complete kernel panics. This vulnerability particularly affects systems using hisilicon Kunpeng 920 processors with the hisi_sec2 cryptographic acceleration driver, making it a significant concern for enterprise network infrastructure and security appliances. The risk is elevated when systems handle substantial encrypted traffic loads, such as VPN connections, IPSec tunnels, or other encrypted network protocols that rely on the affected driver for cryptographic operations.
Mitigation strategies for CVE-2022-50171 require immediate kernel updates to address the core driver implementation issue, ensuring that mutex locks are not used within softirq contexts. System administrators should prioritize patching affected kernel versions, particularly those incorporating the hisi_sec2 driver fixes that prevent mutex acquisition during softirq execution. Additionally, network administrators should monitor for system instability or performance degradation in environments using Kunpeng 920 processors, as these symptoms may indicate the vulnerability's exploitation. The recommended approach involves implementing proper synchronization mechanisms that defer mutex operations to non-atomic contexts, ensuring cryptographic operations maintain system stability while preserving security functionality. Organizations should also consider implementing network segmentation and monitoring to detect unusual packet processing behavior that might indicate exploitation attempts, as the vulnerability's impact can be subtle and may not immediately manifest as system crashes but rather as degraded performance or intermittent connectivity issues.