Re: [REGRESSION] in 6.17, failing __dev_change_net_namespace+0xb89/0xc30

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Oct 15, 2025 at 01:31:20PM -0700, Jakub Kicinski wrote:
> 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?

Oh, I never considered that call-path, and given that I haven't seen a
bug report about this yet, it's pretty rare :)

So yes, that should be checked.  Can anyone knock up a patch for this?
I'm busy all today with other stuff, sorry.

greg k-h