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

[Matthieu Baerts <matttbe@kernel.org>]

Hi Hyunwoo,

Thank you for your reply.

03 Nov 2026 08:29:55 Hyunwoo Kim <imv4bel@gmail.com>:

> On Tue, Sep 08, 2026 at 07:46:19PM +0200, Matthieu Baerts wrote:
>> 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.
>
> Ah.. I had missed this mail.
>
> It seems this issue has not been resolved in netdev yet. May I ask how
> you plan to handle it?

We didn't find a less "intrusive" way to fix that, and it went down the TODO list, sorry.
Do you mind rebasing it, and send a new version including the
decoded trace (without the timestamps), please?

Cheers,
Matt