CVE-2021-47479

What it actually does

Race condition between r871xu_dev_remove() releasing firmware and netdev_open() callback accessing it, resulting in use-after-free of firmware data in rtl8712_dl_fw().

Why it matters to the business

Systems using this legacy staging driver risk kernel crashes, denial of service, or potential code execution leading to downtime or full system compromise, especially on older kernels still carrying the vulnerable code.

How an attack unfolds

An attacker with local access triggers concurrent USB device removal and network interface open operations to hit the window where firmware is freed before netdev unregister, allowing freed memory access during rtl8712_hal_init.

How to fix it

Upgrade the Linux kernel to include commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7 or later; ensure the rtl8712 staging driver is either removed or replaced with a maintained alternative if the hardware is still in use.

How to confirm the fix worked

Verify the presence of the fix commit in the running kernel source tree or confirm that unregister_netdev occurs before release_firmware in hal_init.c; test by exercising device remove and open paths under load.

Typical attack path

1. Obtain local access on affected system
2. Trigger concurrent r871xu_dev_remove and netdev_open paths via USB unplug/replug or module unload/load sequences
3. Force rtl8712_dl_fw execution while firmware pointer is dangling
4. Achieve use-after-free for crash or memory corruption primitives

How to detect it

Review kernel logs and crash dumps for stack traces involving rtl8712_dl_fw, rtl871x_open_fw, r871xu_dev_remove, and release_firmware; search dmesg or syslog for use-after-free warnings tied to the rtl8712 module.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the rtl8712 staging driver
• Audit for and disable or blacklist the rtl8712 module where hardware support is not required
• Monitor for kernel oops or panic logs referencing rtl8712_dl_fw or hal_init.c