CVE-2026-74628: net/x25: fix use-after-free of the socket by its timers
In the Linux kernel, the following vulnerability has been resolved:
net/x25: fix use-after-free of the socket by its timers
The x25 timers are armed with modtimer() and cancelled with timerdelete(), so a pending timer holds no reference on the socket and a cancel does not wait for a callback already running on another CPU.
x25heartbeatexpiry() also rearms unconditionally, so it can reinstall sk->sktimer after x25destroysocket() has passed its cancel point. The following sockput() frees the socket while the timer is still queued, and the next expiry uses freed memory. KASAN reports a slab-use-after-free on the kmalloc-2k object freed by close().
timerdeletesync() cannot be used here: x25heartbeatexpiry() and x25timerexpiry() both reach the cancels from inside the timer they would wait on, through x25destroysocket() and x25disconnect().
Arm the timers with skresettimer() and cancel them with skstoptimer() so that an armed timer owns a reference, and release it in both expiry handlers. Rearm the heartbeat only while skhashed(sk) is still true, since x25destroysocket() unlinks the socket before dropping it. Arm the deferred destroy timer the same way and drop its reference in x25destroytimer().
Reproduced on net with KASAN, with the heartbeat period shortened so the window recurs. With this patch the reproducer no longer triggers a report and /proc/net/x25 drains.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.157.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's X.25 networking code are exposed when X.25 socket timers can remain armed during socket destruction. The issue involves heartbeat, expiry, and deferred-destroy timer handling for X.25 sockets.
What condition triggers the use-after-free?
A socket can be freed after its timers are cancelled without waiting for an already-running callback or without preventing the heartbeat callback from rearming the timer. A later timer expiry can then access the freed socket memory.
How can the issue be mitigated if an updated kernel cannot be deployed immediately?
The provided information does not specify a configuration workaround. Reducing or avoiding use of X.25 sockets would avoid exercising the affected X.25 timer paths.
How can administrators determine whether they have encountered this vulnerability?
The described failure is a slab use-after-free involving a kmalloc-2k object freed during socket close, potentially reported by KASAN. Kernel diagnostics showing X.25 timer callbacks accessing a socket after close are consistent with the issue.