CVE-2022-48926

What it actually does

Missing spinlock protection on the RNDIS response list allows concurrent list_add operations from multiple contexts (such as rndis_msg_parser and rndis_command_complete) to corrupt internal list pointers, triggering list_add corruption and potential kernel panic or memory corruption.

Why it matters to the business

Systems using Linux in USB gadget/RNDIS mode (embedded devices, Android, IoT) may experience sudden crashes or instability under concurrent USB command load, leading to device reboots, loss of connectivity, and operational downtime; high local impact but low external exploitability.

How an attack unfolds

An attacker with local access or the ability to trigger rapid RNDIS control requests (via a malicious host or gadget driver interaction) races multiple list modifications in rndis_add_response/rndis_free_response without synchronization, corrupting the list and causing a kernel crash or potential escalation via the resulting memory state.

How to fix it

Update the Linux kernel to a version containing commit 9f5d8ba538ef81cd86ea587ca3f8c77e26bea405 which adds the required spinlock to rndis_add_response, rndis_free_response, and rndis_get_next_response; rebuild and deploy the patched kernel on affected devices.

How to confirm the fix worked

Verify the running kernel contains commit 9f5d8ba538ef81cd86ea587ca3f8c77e26bea405 or later equivalent; reproduce RNDIS command sequences under load and confirm absence of list_add corruption warnings in dmesg.

Typical attack path

1. Obtain local or USB-adjacent access to a Linux gadget device using the RNDIS function
2. Trigger multiple overlapping RNDIS control or response operations in quick succession
3. Cause concurrent list_add calls on the unprotected rndis response list
4. Trigger list corruption and kernel oops/panic or attempt to leverage corrupted state for code execution

How to detect it

Search kernel logs (dmesg, syslog) for "list_add corruption" messages followed by RNDIS call traces involving rndis_msg_parser or rndis_command_complete; inspect USB gadget event logs for rapid RNDIS request patterns preceding crashes.

• list_add corruption. next->prev should be prev
• rndis_msg_parser+0x168/0x8c0
• rndis_command_complete+0x24/0x84
• __list_add_valid+0x74/0x90

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all devices using USB gadget RNDIS
• Monitor kernel logs for list_add corruption messages on RNDIS-enabled systems
• Disable RNDIS gadget functionality where not required as a temporary mitigation
• Test patched kernels in staging environments before broad deployment