CVE-2021-47163

What it actually does

Use-after-free in TIPC kernel module where a scheduled work queue holding cleanup_bearer() executes after rmmod unmaps the module text, dereferencing freed/invalid memory.

Why it matters to the business

Local unprivileged users can crash the kernel on systems that load and unload the TIPC module, causing denial of service and potential loss of availability for networked services.

How an attack unfolds

An attacker repeatedly issues modprobe tipc, configures a UDP bearer, then rmmod tipc; the delayed work item runs after the module is gone and triggers a paging fault in the removed code path.

How to fix it

Upgrade to a kernel containing the fix that adds wq_count tracking and drains all TIPC work queues in tipc_exit_net() before module exit; apply the stable backport or later kernel release that resolves CVE-2021-47163.

How to confirm the fix worked

Confirm the running kernel version includes the wq_count member in struct tipc_net and the wait in tipc_exit_net(); attempt the documented modprobe/tipc/rmmod sequence and verify no crash occurs.

Typical attack path

1. Load tipc.ko via modprobe or insmod
2. Enable a UDP bearer with tipc bearer enable
3. Unload the module with rmmod tipc
4. Repeat the load/unload cycle until the work queue fires post-unload
5. Kernel dereferences stale function pointer and crashes

How to detect it

Search kernel logs for 'BUG: unable to handle kernel paging request' combined with workqueue events referencing tipc or cleanup_bearer addresses; inspect audit logs for sequences of modprobe tipc followed immediately by rmmod tipc.

• BUG: unable to handle kernel paging request at ffffffffc0
• Workqueue: events .*cleanup_bearer
• tipc bearer enable media udp
• rmmod tipc

What your security team should do

• Prioritize kernel updates on any host that may load TIPC (even transiently)
• Disable TIPC module autoloading via modprobe blacklist if the protocol is unused
• Monitor for repeated TIPC load/unload events in audit logs