CVE-2021-47023 in Linux
Summary
by MITRE • 02/28/2024
In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: fix port event handling on init
For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state.
The crash points to cancel_delayed_work() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig.
The following is the crash which can be triggered:
[ 28.311104] Unable to handle kernel paging request at virtual address
000071775f776600 [ 28.319097] Mem abort info:
[ 28.321914] ESR = 0x96000004
[ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits
[ 28.330350] SET = 0, FnV = 0
[ 28.333430] EA = 0, S1PTW = 0
[ 28.336597] Data abort info:
[ 28.339499] ISV = 0, ISS = 0x00000004
[ 28.343362] CM = 0, WnR = 0
[ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000
[ 28.352842] [000071775f776600] pgd=0000000000000000,
p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 28.365310] Modules linked in: prestera_pci(+) prestera
uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted
5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT)
[ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn
[prestera_pci]
[ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 28.397468] pc : get_work_pool+0x48/0x60
[ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0
[ 28.406018] sp : ffff80001391bc60
[ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000
[ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88
[ 28.420089] x25: 0000000000000000 x24: ffff000106119760
[ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000
[ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0
[ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0
[ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88
[ 28.446898] x15: 0000000000000001 x14: 00000000000002ba
[ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4
[ 28.457622] x11: 0000000000000030 x10: 000000000000000c
[ 28.462985] x9 : 000000000000000c x8 : 0000000000000030
[ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758
[ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60
[ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060
[ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8
[ 28.489791] Call trace:
[ 28.492259] get_work_pool+0x48/0x60
[ 28.495874] cancel_delayed_work+0x38/0xb0
[ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera]
[ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera]
[ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci]
[ 28.516660] process_one_work+0x1e8/0x360
[ 28.520710] worker_thread+0x44/0x480
[ 28.524412] kthread+0x154/0x160
[ 28.527670] ret_from_fork+0x10/0x38
[ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020)
[ 28.537429] ---[ end trace 5eced933df3a080b ]---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/19/2025
The vulnerability CVE-2021-47023 affects the Linux kernel's marvell prestera network driver, specifically within the port event handling mechanism during device initialization. This issue manifests as a kernel oops or system crash when processing port events concurrently with port creation operations. The root cause stems from a race condition where firmware may send initial port events with a down state during the port initialization phase, leading to improper handling of delayed work structures. The crash occurs in the cancel_delayed_work() function which attempts to cancel work items associated with port statistics updates, resulting in a kernel paging request error at virtual address 000071775f776600. This memory access violation demonstrates a classic improper synchronization scenario where work queue operations are not properly coordinated with port state transitions.
The technical flaw resides in the prestera_port_handle_event function within the prestera network driver, where the code fails to properly check the previous port state before attempting to cancel port statistics work items. According to the Linux kernel's workqueue subsystem behavior, the cancel_delayed_work() function expects valid work structures to be in a cancellable state, but when firmware sends an initial down event during port initialization, the work structure may be in an inconsistent state. This vulnerability aligns with CWE-362, which describes a race condition in concurrent programming where two or more threads access shared data concurrently and at least one of the accesses is a write operation. The improper handling of work queue cancellation during port state transitions creates a scenario where the kernel attempts to dereference invalid memory addresses, leading to the kernel oops and system instability.
The operational impact of this vulnerability is significant as it can cause system crashes during network device initialization, particularly on systems using marvell prestera switch hardware such as the AmazonGo1 A7040 board mentioned in the crash logs. The vulnerability affects systems running kernel versions including 5.11.0-rc4 and potentially other versions where the prestera driver is utilized. The crash occurs specifically in the prestera_fw_evt_work_fn workqueue handler, indicating that the issue is triggered when firmware events are processed asynchronously during system boot or device configuration. This could lead to complete system instability, requiring manual intervention or system reboot to recover, making it particularly dangerous in production environments where continuous operation is critical.
Mitigation strategies for this vulnerability involve applying the kernel patch that modifies the port event handling logic to only cancel port statistics work items when the previous port state was up and running. This approach prevents the invalid work structure cancellation that leads to memory access violations. System administrators should upgrade to kernel versions containing the fix, which is typically included in kernel releases following 5.11.0. Additionally, monitoring for system crashes during network device initialization and ensuring proper firmware versions are used can help prevent exploitation of this vulnerability. The fix implements a state validation check before work cancellation, preventing the race condition that causes the kernel oops. This mitigation aligns with ATT&CK technique T1499.001, which involves the exploitation of system resource exhaustion or instability through improper handling of concurrent operations, and follows the principle of least privilege in kernel space operations by ensuring proper synchronization before work queue modifications.