Linux IPv4 flaw: MPTCP is not the whole exposure

Ordinary TCP connections are in scope too

The flaw is a use-after-free in kernel IPv4 option handling. Concurrent operations can still read options that have been freed, including during certain retransmitted connection requests or socket migrations. NVD confirms this mechanism but has no CPE configuration that classifies every distribution.

Red Hat’s bulletin covers systems with a vulnerable kernel and IPv4 TCP enabled, especially those accepting inbound connections. No account or user interaction is required, although reliable code execution needs precise control of the race. Disabling MPTCP alone therefore does not establish that a server is outside the exposure. Red Hat clarifies that RHEL disables MPTCP by default and that an empty list of MPTCP listeners is not a test establishing absence of exposure.

Use your package line, not a universal Linux version

At the 3 November check, Debian lists linux 6.1.190-1 as fixed for bookworm. For trixie, it records 6.12.113-1 as the first fixed version and currently shows 6.12.115-2 in the security repository. Bookworm’s linux-6.12 source package has a separate line, 6.12.113-1~deb12u1. These numbers are not Ubuntu or Red Hat package versions.

At the 3 November check, Ubuntu’s CVE record still marks linux vulnerable on 22.04, 24.04, 26.04 and 26.10, with work in progress. Its technical article says fixes for 22.04, 24.04 and 26.04 are available in -proposed for users able to run their own kernel acceptance tests. The 24.04 threshold is 6.8.0-149.149. That qualification pocket must not be confused with general rollout through updates.

The two Ubuntu pages disagree on 26.10: the article lists 7.3.0-10.10 as fixed, while the CVE record still shows that same version as work in progress. We retain both attributed states rather than declare the branch patched from this reading alone. Have your maintainer confirm the available package and running kernel. HWE and cloud variants still require their own row checks.

The Ubuntu record checked on 5 November adds work-in-progress references for several specialised kernels: linux-nvidia on 26.04 targets 7.0.0-1025.26, linux-nvidia-7.0 on 24.04 targets 7.0.0-1025.26~24.04.1 and linux-nvidia-bos on 26.04 targets 7.0.0-2024.25. These rows remain marked vulnerable with work in progress. An announced package number therefore proves neither availability in your repositories nor activation on the machine.

Red Hat names RHEL 8, 9, 10 and OpenShift, plus products relying on those kernels, and says it is expediting fixes. The bulletin we read gives no universal fixed package. Have the relevant erratum and package confirmed for your system.

Temporary filtering still needs operational checks

Red Hat documents an nftables filter for IPv4 TCP packets containing IP options. It says the measure reduces exposure without fully preventing the issue and may disrupt necessary workloads. IP options are not ordinary TCP options: do not improvise a rule that blocks all TCP traffic. The Red Hat rule is not persistent: it does not survive a reboot. If it is used while awaiting a fix, its presence therefore needs checking after each restart.

Ubuntu’s record, revised on 3 November, now documents this filtering too, with specific prerequisites: nftables, administrator access and no need for IPv4 options. Its persistence recipe assumes nftables manages the firewall without UFW or firewalld. It covers the host, including its connections to itself; containers with separate networking need a separate rule. IPv6 and ordinary TCP options remain outside this block. Ubuntu retains the limitation: filtering reduces risk without fully preventing exploitation.

Ubuntu’s technical article instead considers security updates the only appropriate mitigation and reiterates that disabling MPTCP does not address this general flaw. That advice is stricter than the filtering recipe retained in its CVE record. Do not read the recipe as universal validation of server protection.

Red Hat now publishes guidance for OpenShift Container Platform 4, using nftables rules distributed across nodes through MachineConfig resources and node disruption policies. Its scope remains external traffic: a rule on a node filters only its host network namespace, not pod-to-pod traffic in the OVN-Kubernetes network. Filtering external traffic forwarded to pods also depends on the network configuration. The bulletin does not yet offer a pod-to-pod mitigation and warns that applying rules in every pod’s network namespace would be invasive and introduce a race when pods are created or rescheduled. Kernel security updates remain the only complete solution it identifies. A successful host rule must not be presented as protection for the whole cluster.

Have the network administrator assess the mitigation in a test environment, with backup access and a rollback path. The bulletin says to remove it after updating to a fixed kernel. It is neither proof of immunity nor a permanent substitute for patching.

After installation, check the running kernel

Record the distribution, release, kernel package and exposed services. After applying its vendor’s update, verify that the expected kernel is running and necessary access still works. Plan any required reboot without losing your only administrative path.

The primary sources describe a vulnerability and remediation, not an inspection of your server. We ran no exploit or filtering rule. This brief does not promote press reports of active exploitation, demonstration timings or Go defaults into primary-source findings.

• Plan server updates and recovery↗