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

[Fernando Fernandez Mancera <fmancera@suse.de>]

On 10/16/25 8:25 AM, Greg Kroah-Hartman wrote:
> 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
> 

I can send a patch, I hit this yesterday too.

Thanks,
Fernando.