[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251015133120.7ef53b20@kernel.org>
Date: Wed, 15 Oct 2025 13:31:20 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Cynthia <cynthia@...mx.dev>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Danilo Krummrich <dakr@...nel.org>
Cc: netdev@...r.kernel.org
Subject: Re: [REGRESSION] in 6.17, failing
__dev_change_net_namespace+0xb89/0xc30
On Tue, 14 Oct 2025 10:04:43 +0000 Cynthia wrote:
> When I updated my machine to the newest kernel, a bug started to appear.
> The system does not panic, but an error kept happening in dmesg.
>
> The bug happens with LXC/Incus when it tries to start a new container.
> (but probably other things are affected too)
>
>
> Steps to Reproduce: the bug can be reproduced in a libvirt VM, no need
> for a specific system. Also I suspect the bug is also
> architecture-independent, but I cannot verify that.
> 1) Install ArchLinux (all dependencies are available). I was testing
> with vanilla kernel, so any linux distro should be affected.
> https://aur.archlinux.org/packages/linux-mainline can be installed, this
> is the vanilla kernel with a generally good kernel config for most PCs.
> 2) Install LXC/Incus (pacman -S incus)
> 3) configure incus and start a container:
> usermod -v 1000000-1000999999 -w 1000000-1000999999 root &&
> incus admin init &&
> incus launch images:debian/12 first # start a container
> 4) Previous step should trigger incus to do namespaces. I'm not sure
> what syscall is causing the bug, I do not have a mini C program. These
> steps should be enough to see the log in the dmesg.
>
> I also did a git bisect, the first commit to have this bug is this:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c17270f9b920e4e1777488f1911bbfdaf2af3be
>
> I initially reported this bug on Bugzilla, but after seeing 6 year old
> bugs there, I'm not sure if that platform is still in use.
> https://bugzilla.kernel.org/show_bug.cgi?id=220649
>
> Since my initial report, 6.17.2 was released, the bug is still happening.
>
> I'm attaching 2 files:
> dmesg_slice: the slice of dmesg containing the problematic frame (on a
> bare-metal linux with AMD srso mitigation disabled)
> bisect_log: a log of the git bisect process
Thanks a lot for bisecting! Looking at the code my guess is that sysfs
gives us ENOENT when we try to change owner of a file that isn't
visible. Adding sysfs maintainers - should sysfs_group_attrs_change_owner()
call is_visible before trying to touch the attr?
Powered by blists - more mailing lists