CVE-2021-47321

What it actually does

The watchdog driver's remove path uses del_timer() which does not block until any pending timer handler completes, allowing the handler to continue executing after module memory has been freed and resulting in a use-after-free condition.

Why it matters to the business

Systems running affected Linux kernels may experience crashes, memory corruption, or local privilege escalation during driver unload or device removal events, increasing downtime and security exposure in servers, embedded devices, and cloud workloads.

How an attack unfolds

An attacker with local access triggers repeated module load/unload or device hot-unplug operations while the watchdog timer is armed; because the timer callback can still run after the driver struct is freed, the attacker can arrange for the freed memory to be reused with attacker-controlled data to achieve code execution or denial of service.

How to fix it

Update the Linux kernel to a version containing the fix that replaces del_timer() with del_timer_sync() in the watchdog remove path; rebuild and reboot with the patched kernel; where immediate patching is not possible, avoid unloading the driver and restrict unprivileged access to watchdog device nodes.

How to confirm the fix worked

Inspect the watchdog driver source for the presence of del_timer_sync() in the remove function, verify the running kernel version contains the commit, and confirm that module unload no longer produces use-after-free warnings in the kernel log under load.

Typical attack path

1. Obtain local access on a Linux system using the vulnerable watchdog driver
2. Arm the watchdog timer via the exposed device interface
3. Trigger driver removal or module unload while the timer is pending
4. Reuse the freed timer structure memory to corrupt kernel state or execute arbitrary code

How to detect it

Search kernel logs and audit trails for repeated watchdog module load/unload events followed immediately by use-after-free or timer-related BUG/OOPS messages; correlate with any observed system instability during device removal.

What your security team should do

• Prioritize kernel updates on all systems exposing watchdog drivers, especially those allowing module unload or hotplug
• Harden watchdog device permissions to root-only where feasible
• Monitor kernel logs for timer-related warnings during driver lifecycle events
• Include this class of timer synchronization issues in future kernel patch review processes