CVE-2025-38278

What it actually does

Race condition in octeontx2-pf HTB QoS handling allows TC_HTB_LEAF_DEL_LAST callback to reassign send queues without first stopping active traffic or properly marking the node as Inner, leading to invalid queue updates after device unregistration and kernel warnings.

Why it matters to the business

Systems running affected Linux kernel versions may experience boot-time warnings, potential network queue instability, or denial of service on reboot; high downstream prevalence in Linux distributions increases exposure for servers and embedded devices.

How an attack unfolds

An attacker with local access triggers rapid HTB leaf node deletion and traffic patterns during interface teardown to race the queue reassignment logic, potentially escalating to kernel warnings or instability; listed threat actors and campaigns have been observed targeting similar Linux kernel races for privilege escalation.

How to fix it

Upgrade linux-lts (Alpaquita:stream) to 6.6.58-r0 or newer, linux-lts (Alpaquita:23) to 6.1.62-r0 or newer, or apply the stable kernel commit 5df8db01d6a4e9c35a5ba5d7e130d5cecd3ffcb4; rebuild and reboot after patching.

How to confirm the fix worked

Confirm kernel version contains the referenced commit or fixed package versions; reproduce reboot with active HTB traffic and verify absence of netdev_queue_update_kobjects warnings in dmesg.

Typical attack path

1. Obtain local access on affected Linux system
2. Configure HTB qdisc with leaf nodes carrying active traffic
3. Trigger interface down or reboot sequence to invoke TC_HTB_LEAF_DEL_LAST
4. Race the send-queue reassignment before Inner marking occurs
5. Observe kernel warnings or induce queue registration failure

How to detect it

Review kernel logs (dmesg, journalctl) around boot and interface events for netdev_queue_update_kobjects warnings; correlate with HTB qdisc configuration changes or traffic on octeontx2-pf interfaces; inspect for activity by the named threat actors in related kernel exploitation campaigns.

What your security team should do

• Prioritize patching all systems using the listed fixed versions within 30 days given 474 days of public exposure
• Monitor EPSS trend and threat actor activity around similar kernel races for elevated urgency
• Restrict unprivileged local access on multi-tenant or exposed Linux hosts until patched