CVE-2024-50019

What it actually does

Calling kthread_stop on an already-unparked per-CPU kthread triggers an unconditional kthread_bind which assumes TASK_PARKED state, producing a kernel warning during workqueue destruction paths such as wg_destruct and net namespace cleanup.

Why it matters to the business

Linux systems may experience kernel warnings or operational instability when destroying network devices or cleaning up namespaces; widespread use of the kernel in servers and network appliances raises exposure across many environments, with no ransomware association but listed in broad 2024 exploitation campaign reporting.

How an attack unfolds

No direct attacker exploitation path exists; the condition surfaces during legitimate kernel operations that stop per-CPU kthreads (for example, WireGuard device teardown or network namespace exit) after the kthread has already been unparked, and threat actor references to Linux kernel resource and bounds issues remain unrelated to this specific fix.

How to fix it

Apply the upstream fix (commit 40a6e660d2a3a7a5cb99f0b8ff4fb41bad039f68) or upgrade to a kernel containing it; Rocky Linux 8 users should install bind 2:9.11.26-6.el8 or later equivalent that incorporates the change.

How to confirm the fix worked

Confirm the patch is present by checking the kthread.c source for the added early return before kthread_bind in kthread_stop; reproduce the prior scenario (destroy_wireguard_device or netns cleanup) and verify absence of the __kthread_bind_mask warning.

Typical attack path

1. Trigger normal kernel workqueue or network device shutdown
2. kthread_stop invoked on a per-CPU kthread that is no longer parked
3. kthread_bind called on non-TASK_PARKED task
4. WARNING emitted at kernel/kthread.c:525

How to detect it

Search kernel logs and dmesg for the exact warning string emitted from kthread.c during workqueue or net device destruction; correlate with WireGuard or network namespace cleanup events.

• WARNING: CPU: .* PID: .* at kernel/kthread.c:525 __kthread_bind_mask
• kthread_stop+0x17a/0x630 kernel/kthread.c:707
• wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257

What your security team should do

• Prioritize kernel updates on all systems running affected stable trees
• Monitor kernel logs for the specific kthread_bind warning during device or namespace teardown
• Test WireGuard and network namespace shutdown paths after patching