netdev - Re: [PATCH v2 mptcp] mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <30663725-7078-4b8d-bc75-8a9cd15b0b02@kernel.org>
Date: Tue, 25 Feb 2025 22:41:55 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: Krister Johansen <kjlx@...pleofstupid.com>
Cc: Mat Martineau <martineau@...nel.org>, Geliang Tang <geliang@...nel.org>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
 mptcp@...ts.linux.dev
Subject: Re: [PATCH v2 mptcp] mptcp: fix 'scheduling while atomic' in
 mptcp_pm_nl_append_new_local_addr

Hi Krister,

On 25/02/2025 20:29, Krister Johansen wrote:
> Hi Matt,
> Thanks for the review!
> 
> On Tue, Feb 25, 2025 at 06:52:45PM +0100, Matthieu Baerts wrote:
>> On 25/02/2025 00:20, Krister Johansen wrote:
>>> If multiple connection requests attempt to create an implicit mptcp
>>> endpoint in parallel, more than one caller may end up in
>>> mptcp_pm_nl_append_new_local_addr because none found the address in
>>> local_addr_list during their call to mptcp_pm_nl_get_local_id.  In this
>>> case, the concurrent new_local_addr calls may delete the address entry
>>> created by the previous caller.  These deletes use synchronize_rcu, but
>>> this is not permitted in some of the contexts where this function may be
>>> called.  During packet recv, the caller may be in a rcu read critical
>>> section and have preemption disabled.
>>
>> Thank you for this patch, and for having taken the time to analyse the
>> issue!
>>
>>> An example stack:

(...)

>> Detail: if possible, next time, do not hesitate to resolve the
>> addresses, e.g. using: ./scripts/decode_stacktrace.sh
> 
> My apologies for the oversight here.  This is the decoded version of the
> stack:

No problem, thanks for the decoded version!

(...)

>> I'm going to apply it in our MPTCP tree, but this patch can also be
>> directly applied in the net tree directly, not to delay it by one week
>> if preferred. If not, I can re-send it later on.
> 
> Thanks, I'd be happy to send it to net directly now that it has your
> blessing.  Would you like me to modify the call trace in the commit
> message to match the decoded one that I included above before I send it
> to net?

Sorry, I forgot to mention that this bit was for the net maintainers.
Typically, trivial patches and small fixes related to MPTCP can go
directly to net.

No need for you to re-send it. If the net maintainers prefer me to send
it later with other patches (if any), I will update the call trace, no
problem!

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