CVE-2025-68245

What it actually does

Incorrect refcount handling in netpoll causes premature RCU_INIT_POINTER of dev->npinfo to NULL on first cleanup when multiple netpolls share npinfo, skipping do_netpoll_cleanup and leaking npinfo plus skb pools on subsequent cleanups.

Why it matters to the business

Memory leaks in the networking stack on Linux systems using netpoll (debugging, monitoring, or specialized NIC configurations) can lead to gradual resource exhaustion, degraded performance, or eventual instability requiring reboots; high downstream prevalence in Linux distributions increases patch urgency despite low exploitability.

How an attack unfolds

An attacker with local access or ability to trigger netpoll attachment/detachment (via tools or misconfigured services) associates multiple netpolls with the same NIC, forces sequential cleanups, and triggers the refcount bypass to leak kernel memory structures without triggering normal skb pool release.

How to fix it

Upgrade the Linux kernel to commit 8e6a50edad11e3e1426e4c29e7aa6201f3468ac2 or later; for AlmaLinux 9 systems apply the fixed package versions such as gcc-toolset-13-gcc 13.3.1-2.2.el9_5 and equivalent updates for libasan8, liblsan, libtsan2 and related gcc-toolset-13 packages.

How to confirm the fix worked

Verify kernel source contains the revert of efa95b01da18 and updated refcount checks before npinfo cleanup; confirm affected AlmaLinux packages report the listed fixed versions; run kmemleak or slabinfo monitoring under repeated netpoll attach/detach cycles to validate absence of leaks.

Typical attack path

1. Attach first netpoll to NIC, allocating npinfo with refcnt=1
2. Attach second netpoll to same NIC, incrementing shared npinfo refcnt to 2
3. Trigger cleanup on first netpoll, which ignores refcnt and nulls dev->npinfo
4. Trigger cleanup on second netpoll, which finds npinfo already NULL and skips do_netpoll_cleanup
5. Observe leaked npinfo and skb pool memory via kmemleak or resource monitoring

How to detect it

Search kernel logs and kmemleak output for repeated netpoll allocation without matching cleanup entries; monitor for growing skb pool or npinfo allocations tied to netdev structures; no public exploitation artifacts exist so focus on post-patch memory accounting diffs.

What your security team should do

• Prioritize kernel and affected gcc-toolset package updates on all Linux systems within standard change windows
• Audit configurations using netpoll (e.g., netconsole, kgdb over net) and minimize shared NIC usage where possible
• Monitor kmemleak reports and memory usage trends on production kernels until patches are deployed