On October 27, LLM provider Anthropic reported on a

remotely exploitable use-after-free bug affecting systems with multipath TCP listeners open. The bug works by triggering a response to a retransmitted SYN packet at the same moment that the TCP connection is established in another thread, causing the first thread to access the connection's options structure after the second thread has freed it. The first thread can then disclose kernel memory or cause a buffer overflow, writing an attacker-controlled payload. The fix was

to only free the structure after an RCU grace period. On October 29, the Go security team advised that all programs written in Go use multipath TCP by default, so many systems may be unknowingly vulnerable. And, of course, there is always the possibility of related bugs in other sections of the TCP stack. Users may be wise to update to a patched kernel as soon as one becomes available for their distribution.

So... hmm... Kubernetes?

Posted Oct 30, 2026 19:10 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I compile my own kernel packages and the sysctl command you gave failed. So I checked:

$ grep -i mptcp /boot/config-7.3.1

CONFIG_MPTCP is not set

I guess I'm accidentally safe.

So... hmm... Kubernetes?

Posted Oct 31, 2026 1:22 UTC (Sat) by job (guest, #670) [Link]

This is bad

Posted Oct 30, 2026 21:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

. . . at least for the newer versions - I can say for sure about the 6.12.y branch, and given it goes back to the 4.4 kernel I'd be surprised if it hasn't been backported to all the active LTS releases.

The backported fix in the 6.12.y branch is:

commit 11a03ce3c4a62d84c10ccdfe47f8075006498568 Author: Eric Dumazet edumazet@kernel.org Date: Thu Oct 1 22:12:53 2026 +0000

ipv4: free inet_opt and ireq_opt after an RCU grace period

commit e3f33b0a1d89d738e2b913dab519226eaf76e15b upstream.

The RCE is the scary thing here, particularly given Go's behaviour.

One positive from the last six months of kernel hell is that at my organisation we're proactively following the 6.12 LTS releases, with no more than a two week lag on deployment (unless there's a serious known vulnerability in play, which was actually the case for 6.12.113) - that means when this RCE was announced I could sit back and enjoy the fact that my externally exposed systems had been safe for several weeks.