CVE-2025-22057

What it actually does

Use-after-free in Linux kernel dst cache handling: dst_release fails to invalidate cached dst entries when CONFIG_DST_CACHE is enabled with OvS and tunnels, allowing percpu_counter_add_batch to access already-freed memory during netns dismantle or dst_destroy_rcu.

Why it matters to the business

Kernel crashes or memory corruption on systems running OvS with tunnels can cause service outages, require emergency reboots, and open paths for local privilege escalation; widespread in Linux-based infrastructure and cloud environments.

How an attack unfolds

An attacker with local access triggers repeated dst allocation and release paths through OvS tunnel traffic or network namespace teardown, racing the incomplete counter decrement to hit the freed percpu counter and achieve arbitrary read/write or denial of service.

How to fix it

Update the Linux kernel to commit ccc331fd5bcae131d2627d5ef099d4a1f6540aea or later; for affected Red Hat packages apply tigervnc updates to version 1.12.0-15.el8_8.11 or newer; rebuild and reboot systems using OvS tunnels; disable CONFIG_DST_CACHE where operationally feasible as a temporary mitigation.

How to confirm the fix worked

Verify kernel version contains commit ccc331fd5bcae131d2627d5ef099d4a1f6540aea; confirm no crash on dst_release under CONFIG_DST_CACHE with OvS tunnels; run regression tests exercising dst_cache_destroy during namespace teardown.

Typical attack path

1. Obtain local unprivileged access on a Linux host using OvS with tunnels
2. Force dst cache population via crafted network flows or namespace operations
3. Trigger concurrent dst_release and dst_cache_destroy during netns dismantle
4. Access freed percpu counter structure to corrupt kernel memory
5. Escalate to root or crash the kernel

How to detect it

Search kernel logs for percpu_counter_add_batch call traces during dst_release or dst_cache_destroy; inspect for repeated netns dismantle events coinciding with crashes; review audit logs for unusual OvS tunnel or namespace activity preceding kernel faults.

What your security team should do

• Prioritize kernel updates on all hosts using OvS or tunnels within 30 days
• Monitor for kernel oops involving percpu_counter_add_batch and dst_release
• Restrict unprivileged namespace creation until patched
• Test patches in staging environments before broad rollout