netdev - Re: Data race in net/mptcp/pm

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] [day] [month] [year] [list]

Message-ID: <27e36417-9c22-476b-a9be-f22deeb0d774@kernel.org>
Date: Fri, 22 Nov 2024 12:50:34 +0100
From: Matthieu Baerts <matttbe@...nel.org>
To: clingfei <clf700383@...il.com>, 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, linux-kernel@...r.kernel.org
Subject: Re: Data race in net/mptcp/pm_netlink.c

Hello,

On 22/11/2024 08:34, clingfei wrote:
> linux-next weekly scan reports that there might be data race in
> net/mptcp/pm_netlink.c, when mptcp_pm_nl_flush_addrs_doit
> bitmap_zeroing pernet->id_bit_map at line 1748, there might be a
> concurrent read at line 1864.
> Should we add a lock to protect pernet->id_bit_map?

I don't think there is an issue here: if the flush is being done in
parallel to an in progress dump (max 255 addresses), I don't know what
the userspace can really expect. What's important is not to access freed
data, which should be prevented by the 'rcu_read_lock()'.

So it looks like no lock or id_bitmap duplication is needed here. Even
if there was a need for a certain consistency there, these 2 operations
should not happen in parallel, because the MPTCP generic NL family
doesn't have ".parallel_ops = true".

So I think this report is a false positive, no?

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