CVE-2026-68170

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix stale skb-&gt;sk reference on subflow close<br /> <br /> The backlog list is updated by mptcp_data_ready() under<br /> mptcp_data_lock(). The cleanup of backlog references to a closing<br /> subflow, however, was performed in mptcp_close_ssk(), before<br /> __mptcp_close_ssk() acquires the ssk lock, and while holding neither<br /> the ssk lock nor mptcp_data_lock().<br /> <br /> Because that traversal ran without mptcp_data_lock(), concurrent softirq<br /> RX processing on another CPU (subflow_data_ready() -&gt; mptcp_data_ready()<br /> -&gt; __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog<br /> entry referencing the ssk while the cleanup loop was in progress. Such<br /> an entry could be missed by the cleanup, or the concurrent list update<br /> could corrupt the traversal, leaving skb-&gt;sk pointing at the ssk after<br /> it is freed.<br /> <br /> A later mptcp_backlog_purge() then dereferences the stale pointer,<br /> triggering a warning in inet_sock_destruct() (ssk-&gt;sk_rmem_alloc != 0)<br /> followed by a use-after-free in mptcp_backlog_purge().<br /> <br /> Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after<br /> subflow-&gt;closing is set to 1 and while the ssk lock is still held,<br /> serialized under mptcp_data_lock(). The cleanup runs only on the push<br /> path (MPTCP_CF_PUSH), where backlog references accumulate; on other<br /> teardown paths the caller already handles cleanup.<br /> <br /> With subflow-&gt;closing set and mptcp_data_lock() held across the purge,<br /> any concurrent mptcp_data_ready() either completes its enqueue before<br /> the purge runs and is caught, or observes closing=1 and bails out. Once<br /> mptcp_data_unlock() is reached, no new skb referencing the ssk can be<br /> enqueued, so the cleanup is exhaustive.<br /> <br /> Remove the unprotected traversal from mptcp_close_ssk() entirely.