linux-kernel - Re: [PATCH net v2] net: Avoid calling WARN_ON() on -ENOMEM in netif_change_net

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: <20250407131930.70ad6df9d1e8c1f7c413f880@mt-integration.ru>
Date: Mon, 7 Apr 2025 13:19:30 +0300
From: Ivan Abramov <i.abramov@...integration.ru>
To: Eric Dumazet <edumazet@...gle.com>
CC: Stanislav Fomichev <stfomichev@...il.com>, "David S. Miller"
	<davem@...emloft.net>,
	<syzbot+1df6ffa7a6274ae264db@...kaller.appspotmail.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
	<horms@...nel.org>, Kuniyuki Iwashima <kuniyu@...zon.com>, "Stanislav
 Fomichev" <sdf@...ichev.me>, Ahmed Zaki <ahmed.zaki@...el.com>, "Alexander
 Lobakin" <aleksander.lobakin@...el.com>, "Eric W. Biederman"
	<ebiederm@...ssion.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <lvc-project@...uxtesting.org>
Subject: Re: [PATCH net v2] net: Avoid calling WARN_ON() on -ENOMEM in
 netif_change_net_namespace()

On Fri, 4 Apr 2025 10:53:35 +0200, Eric Dumazet wrote:
> On Fri, Apr 4, 2025 at 9:29 AM Ivan Abramov <i.abramov@...integration.ru> wrote:
>>
>> On Thu, 3 Apr 2025 11:05:31 -0700, Stanislav Fomichev wrote:
>> > On 04/03, Ivan Abramov wrote:
>> >> It's pointless to call WARN_ON() in case of an allocation failure in
>> >> device_rename(), since it only leads to useless splats caused by deliberate
>> >> fault injections, so avoid it.
>>
>> > What if this happens in a non-fault injection environment? Suppose
>> > the user shows up and says that he's having an issue with device
>> > changing its name after netns change. There will be no way to diagnose
>> > it, right?
>>
>> Failure to allocate a few hundred bytes in kstrdup doesn't seem
>> practically possible and happens only in fault injection scenarios. Other
>> types of failures in device_rename will still trigger WARN_ON.
>
> If you want to fix this, fix it properly.
>
> Do not paper around the issue by silencing a warning.

As far as I know, WARN_ON call on -ENOMEM is the issue itself, since
it only fires in testing/deliberate scenarios. And this fixes just that,
without touching anything else.

How should proper fix of this look like? I would be glad to work up
some solution that satisfies maintainers' vision, but I don't see other
ways around it without some grand refactoring, which may bring more
problems than solutions.