netdev - Re: [PATCH net] batman-adv: Hold rtnl lock during MTU update via netlink

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: <20230822075539.GU2711035@kernel.org>
Date: Tue, 22 Aug 2023 09:55:39 +0200
From: Simon Horman <horms@...nel.org>
To: Sven Eckelmann <sven@...fation.org>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	b.a.t.m.a.n@...ts.open-mesh.org, netdev@...r.kernel.org,
	stable@...r.kernel.org,
	syzbot+f8812454d9b3ac00d282@...kaller.appspotmail.com
Subject: Re: [PATCH net] batman-adv: Hold rtnl lock during MTU update via
 netlink

On Mon, Aug 21, 2023 at 09:48:48PM +0200, Sven Eckelmann wrote:
> The automatic recalculation of the maximum allowed MTU is usually triggered
> by code sections which are already rtnl lock protected by callers outside
> of batman-adv. But when the fragmentation setting is changed via
> batman-adv's own batadv genl family, then the rtnl lock is not yet taken.
> 
> But dev_set_mtu requires that the caller holds the rtnl lock because it
> uses netdevice notifiers. And this code will then fail the check for this
> lock:
> 
>   RTNL: assertion failed at net/core/dev.c (1953)
> 
> Cc: stable@...r.kernel.org
> Reported-by: syzbot+f8812454d9b3ac00d282@...kaller.appspotmail.com
> Fixes: c6a953cce8d0 ("batman-adv: Trigger events for auto adjusted MTU")
> Signed-off-by: Sven Eckelmann <sven@...fation.org>

Reviewed-by: Simon Horman <horms@...nel.org>

> ---
> This problem was just identified by syzbot [1]. I hope it is ok to directly
> send this patch to netdev instead of creating a single-patch PR from
> the batadv/net branch. If you still prefer a PR then we can also prepare
> it.
> 
> [1] https://lore.kernel.org/r/0000000000009bbb4b0603717cde@google.com

...