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

[Jakub Kicinski <kuba@kernel.org>]

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?