* Re: [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer()
[not found] <20251117100745.1913963-1-edumazet@google.com>
@ 2025-11-17 10:15 ` Matthieu Baerts
2025-11-17 10:21 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: Matthieu Baerts @ 2025-11-17 10:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mat Martineau, Geliang Tang, Florian Westphal, netdev,
eric.dumazet, syzbot+2a6fbf0f0530375968df, Geliang Tang,
MPTCP Linux, David S . Miller, Jakub Kicinski, Paolo Abeni
Hi Eric,
(+cc MPTCP ML)
On 17/11/2025 11:07, Eric Dumazet wrote:
> mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)
> while another might have free entry already, as reported by syzbot.
>
> Add RCU protection to fix this issue.
Thank you for the report and even more for the fix!
> Also change confusing add_timer variable with stop_timer boolean.
Indeed, this name was confusing: 'add_timer' is in fact a (too) short
version of "additional address signalling retransmission timer". This
new 'stop_timer' boolean makes sense!
> syzbot report:
(...)
> Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout")
> Reported-by: syzbot+2a6fbf0f0530375968df@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/691ad3c3.a70a0220.f6df1.0004.GAE@google.com/
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Geliang Tang <geliang@kernel.org>
The modification looks good to me:
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
While at it, just to help me to manage the backports:
Cc: stable@vger.kernel.org
> v2: Updated/Added Reported-by:/Closes: tags now syzbot report finally reached netdev@ mailing list.
Out of curiosity, is it not OK to reply to the patch with the new
Reported-by & Closes tags to have them automatically added when applying
the patch? (I was going to do that on the v1, then I saw the v2 just
when I was going to press 'Send' :) )
I don't mind having a v2, it is just to save you time later, but maybe
there is another reason.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer()
2025-11-17 10:15 ` [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer() Matthieu Baerts
@ 2025-11-17 10:21 ` Eric Dumazet
2025-11-17 10:42 ` Matthieu Baerts
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2025-11-17 10:21 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Mat Martineau, Geliang Tang, Florian Westphal, netdev,
eric.dumazet, syzbot+2a6fbf0f0530375968df, Geliang Tang,
MPTCP Linux, David S . Miller, Jakub Kicinski, Paolo Abeni
On Mon, Nov 17, 2025 at 2:15 AM Matthieu Baerts <matttbe@kernel.org> wrote:
>
> Hi Eric,
>
> (+cc MPTCP ML)
>
> On 17/11/2025 11:07, Eric Dumazet wrote:
> > mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)
> > while another might have free entry already, as reported by syzbot.
> >
> > Add RCU protection to fix this issue.
>
> Thank you for the report and even more for the fix!
>
> > Also change confusing add_timer variable with stop_timer boolean.
>
> Indeed, this name was confusing: 'add_timer' is in fact a (too) short
> version of "additional address signalling retransmission timer". This
> new 'stop_timer' boolean makes sense!
>
> > syzbot report:
>
> (...)
>
> > Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout")
> > Reported-by: syzbot+2a6fbf0f0530375968df@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/netdev/691ad3c3.a70a0220.f6df1.0004.GAE@google.com/
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Geliang Tang <geliang@kernel.org>
>
> The modification looks good to me:
>
> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>
> While at it, just to help me to manage the backports:
>
> Cc: stable@vger.kernel.org
>
> > v2: Updated/Added Reported-by:/Closes: tags now syzbot report finally reached netdev@ mailing list.
>
> Out of curiosity, is it not OK to reply to the patch with the new
> Reported-by & Closes tags to have them automatically added when applying
> the patch? (I was going to do that on the v1, then I saw the v2 just
> when I was going to press 'Send' :) )
I am not sure patchwork has been finally changed to understand these two tags.
>
> I don't mind having a v2, it is just to save you time later, but maybe
> there is another reason.
>
> Cheers,
> Matt
> --
> Sponsored by the NGI0 Core fund.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer()
2025-11-17 10:21 ` Eric Dumazet
@ 2025-11-17 10:42 ` Matthieu Baerts
2025-11-18 1:05 ` Jakub Kicinski
0 siblings, 1 reply; 5+ messages in thread
From: Matthieu Baerts @ 2025-11-17 10:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mat Martineau, Geliang Tang, Florian Westphal, netdev,
eric.dumazet, syzbot+2a6fbf0f0530375968df, Geliang Tang,
MPTCP Linux, David S . Miller, Jakub Kicinski, Paolo Abeni
On 17/11/2025 11:21, Eric Dumazet wrote:
> On Mon, Nov 17, 2025 at 2:15 AM Matthieu Baerts <matttbe@kernel.org> wrote:
>>
>> Hi Eric,
>>
>> (+cc MPTCP ML)
>>
>> On 17/11/2025 11:07, Eric Dumazet wrote:
>>> mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)
>>> while another might have free entry already, as reported by syzbot.
>>>
>>> Add RCU protection to fix this issue.
>>
>> Thank you for the report and even more for the fix!
>>
>>> Also change confusing add_timer variable with stop_timer boolean.
>>
>> Indeed, this name was confusing: 'add_timer' is in fact a (too) short
>> version of "additional address signalling retransmission timer". This
>> new 'stop_timer' boolean makes sense!
>>
>>> syzbot report:
>>
>> (...)
>>
>>> Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout")
>>> Reported-by: syzbot+2a6fbf0f0530375968df@syzkaller.appspotmail.com
>>> Closes: https://lore.kernel.org/netdev/691ad3c3.a70a0220.f6df1.0004.GAE@google.com/
>>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>>> Cc: Geliang Tang <geliang@kernel.org>
>>
>> The modification looks good to me:
>>
>> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>>
>> While at it, just to help me to manage the backports:
>>
>> Cc: stable@vger.kernel.org
>>
>>> v2: Updated/Added Reported-by:/Closes: tags now syzbot report finally reached netdev@ mailing list.
>>
>> Out of curiosity, is it not OK to reply to the patch with the new
>> Reported-by & Closes tags to have them automatically added when applying
>> the patch? (I was going to do that on the v1, then I saw the v2 just
>> when I was going to press 'Send' :) )
>
> I am not sure patchwork has been finally changed to understand these two tags.
Ah yes, thank you! If there is a dependence on Patchwork, I think
indeed, it doesn't recognise the 'Closes' tag (but I think 'Reported-by'
is OK).
While at it, I forgot to add: this patch can be applied in net directly.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer()
2025-11-17 10:42 ` Matthieu Baerts
@ 2025-11-18 1:05 ` Jakub Kicinski
2025-11-18 2:35 ` Matthieu Baerts
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Kicinski @ 2025-11-18 1:05 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Eric Dumazet, Mat Martineau, Geliang Tang, Florian Westphal,
netdev, eric.dumazet, syzbot+2a6fbf0f0530375968df, Geliang Tang,
MPTCP Linux, David S . Miller, Paolo Abeni
On Mon, 17 Nov 2025 11:42:31 +0100 Matthieu Baerts wrote:
> >> Out of curiosity, is it not OK to reply to the patch with the new
> >> Reported-by & Closes tags to have them automatically added when applying
> >> the patch? (I was going to do that on the v1, then I saw the v2 just
> >> when I was going to press 'Send' :) )
> >
> > I am not sure patchwork has been finally changed to understand these two tags.
>
> Ah yes, thank you! If there is a dependence on Patchwork, I think
> indeed, it doesn't recognise the 'Closes' tag (but I think 'Reported-by'
> is OK).
>
> While at it, I forgot to add: this patch can be applied in net directly.
FWIW I have a local script which extracts them from patchwork comments
and applies them (same for Fixes tags). But it's always safer to resend.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer()
2025-11-18 1:05 ` Jakub Kicinski
@ 2025-11-18 2:35 ` Matthieu Baerts
0 siblings, 0 replies; 5+ messages in thread
From: Matthieu Baerts @ 2025-11-18 2:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Eric Dumazet, Mat Martineau, Geliang Tang, Florian Westphal,
netdev, eric.dumazet, syzbot+2a6fbf0f0530375968df, Geliang Tang,
MPTCP Linux, David S . Miller, Paolo Abeni
Hi Jakub,
Thank you for your reply!
18 Nov 2025 02:05:12 Jakub Kicinski <kuba@kernel.org>:
> On Mon, 17 Nov 2025 11:42:31 +0100 Matthieu Baerts wrote:
>>>> Out of curiosity, is it not OK to reply to the patch with the new
>>>> Reported-by & Closes tags to have them automatically added when applying
>>>> the patch? (I was going to do that on the v1, then I saw the v2 just
>>>> when I was going to press 'Send' :) )
>>>
>>> I am not sure patchwork has been finally changed to understand these two tags.
>>
>> Ah yes, thank you! If there is a dependence on Patchwork, I think
>> indeed, it doesn't recognise the 'Closes' tag (but I think 'Reported-by'
>> is OK).
>>
>> While at it, I forgot to add: this patch can be applied in net directly.
>
> FWIW I have a local script which extracts them from patchwork comments
> and applies them (same for Fixes tags).
Great, good to know, thanks!
(So similar to what "b4 shazam -Msl" would do then.)
> But it's always safer to resend.
Indeed.
Cheers,
Matt
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-11-18 2:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20251117100745.1913963-1-edumazet@google.com>
2025-11-17 10:15 ` [PATCH v2 net] mptcp: fix a race in mptcp_pm_del_add_timer() Matthieu Baerts
2025-11-17 10:21 ` Eric Dumazet
2025-11-17 10:42 ` Matthieu Baerts
2025-11-18 1:05 ` Jakub Kicinski
2025-11-18 2:35 ` Matthieu Baerts
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox