Re: [PATCH net] mptcp: fix use-after-free of the subflow context on the delegated list

[Matthieu Baerts <matttbe@kernel.org>]

Hi Hyunwoo,

On 20/08/2026 14:05, Hyunwoo Kim wrote:
> On Wed, Aug 19, 2026 at 12:22:18PM +0200, Matthieu Baerts wrote:
>> Hi Hyunwoo,
>>
>> On 19/08/2026 12:13, Hyunwoo Kim wrote:
>>> mptcp_subflow_delegate() links the subflow context into a per-CPU napi
>>> list and takes a reference on the subflow socket. The context is a
>>> separate allocation, reached through icsk_ulp_data, and the list holds
>>> no reference to it.
>>>
>>> inet_csk_destroy_sock() runs sk_prot->destroy() regardless of the
>>> outstanding references. That path ends in tcp_cleanup_ulp(), which calls
>>> subflow_ulp_release(). subflow_ulp_release() frees the context with
>>> kfree_rcu() but does not remove it from the list. Once the grace period
>>> elapses and the context is actually freed, the next mptcp_napi_poll()
>>> dequeues that entry and mptcp_subflow_delegated_next() writes to the
>>> freed context with list_del_init(). That is the use-after-free.
>>>
>>> The freeing path cannot dequeue the entry itself: the list is per-CPU
>>> and only the CPU that queued the subflow may touch it, as
>>> tcp_release_cb_override() already notes.
>>>
>>> Delay the free instead. Add MPTCP_DELEGATE_DEAD.
>>> mptcp_subflow_free_ctx() sets it and frees the context only if the
>>> subflow is not scheduled, while mptcp_napi_poll() frees it if the dead
>>> bit is set when it clears the scheduled bit. Either
>>> mptcp_subflow_free_ctx() gets there first, sees the scheduled bit and
>>> leaves the free to mptcp_napi_poll(), or mptcp_napi_poll() gets there
>>> first, does not see the dead bit and mptcp_subflow_free_ctx() does the
>>> free.
>>>
>>> Also skip mptcp_subflow_process_delegated() once the dead bit is set.
>>> subflow_ulp_release() has already dropped the msk reference by then, so
>>> the pending actions must not run.
>>>
>>> Finally, move delegated_status out of struct_group(reset).
>>> mptcp_subflow_ctx_reset() clears that group on disconnect, and clearing
>>> the scheduled bit while the entry is still queued would let
>>> mptcp_subflow_free_ctx() free a context the napi list still points to.
>>> delegated_node is already outside the group.
>> Thank you for looking at this. Do you have more context about how the
>> bug was discovered? Do you have a reproducer and/or a KASAN calltrace or
>> similar?
>>
>> Having this would help the reviewers.
> 
> Sorry for the late reply. The poc was extremely unstable, so I wanted 
> to improve its reproduction rate a bit before sending it.

No delay at all when compared to my reply, sorry!
> Attached are the poc, the KASAN log, and the mdelay diff used for 
> reproduction.

By chance, do you have a decoded stack trace? e.g. using the following
script with the vmlinux and modules used to generate the KASAN trace:

  ./scripts/decode_stacktrace.sh

Note that we are still looking at a possible simpler fix, but no luck so
far. In any cases, we will take this patch in our tree first, then send
it to netdev.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.