CVE-2026-72383

This CVE exposes a race condition in SCTP's address workqueue teardown where timer_delete() was used instead of timer_shutdown_sync(). The difference matters: timer_delete() marks a timer for deletion and returns immediately, while timer_shutdown_sync() blocks until any in-flight handler completes. During SCTP association cleanup, the original code freed addr_waitq after calling timer_delete() — but the timer handler (addr_wq_timeout_handler) could still be running, holding addr_wq_lock and referencing the now-freed wait queue. This creates a use-after-free in a handler that re-acquires a lock, meaning the failure cascades from memory corruption into lock state corruption. Apply the fix immediately: replace timer_delete() with timer_shutdown_sync() in the SCTP address workqueue cleanup path. But beyond this specific fix, treat this as a class vulnerability. Search your kernel tree for timer_delete() calls in any teardown or cleanup path — especially in network subsystems where SCTP, DCCP, or other protocols handle untrusted input. The blast radius of timer teardown races in network-facing code is materially worse than in isolated drivers because the trigger can originate from external network traffic. The kernel has safe timer APIs; the problem is scattered, inconsistent usage of the unsafe variant in paths where the safe one is appropriate. Audit your timer teardown paths now, not because the documentation is unclear, but because the safer primitive exists alongside the dangerous one with no automated warning to catch the mismatch.

Reviewed through automated stages and approved by a human before publication.