linux-kernel - Re: Linux 6.18-rc6

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aR2JE-wBHlTTO4YX@kuha>
Date: Wed, 19 Nov 2025 11:08:35 +0200
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Stephanie Gawroriski <xerthesquirrel@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Linux 6.18-rc6

Hi

> > > Unrelated to this, after suspending and docking my laptop to my dock, I
> > > get
> > > this now:
> > > 
> > > [50598.774359] ------------[ cut here ]------------
> > > [50598.774371] kernfs: can not remove 'typec', no directory
> > > [50598.774389] WARNING: CPU: 2 PID: 48932 at fs/kernfs/dir.c:1706
> > > kernfs_remove_by_name_ns+0xcf/0xe0
> > 
> > Ok, that is indeed unrelated, and should be mostly harmless apart from
> > the scary message. Do you see any other effects than the noise in the
> > logs?
> 
> Not that I know of.
> 
> > Somebody is trying to remove a sysfs entry that has no parent,
> > presumably because it was never registered in the first place.
> > 
> > At a guess, it's some error handling cleanup that is done
> > unconditionally, unregistering an entry even when the original
> > registration failed. Or unregistering twice.
> > 
> > Looks like ucsi / typec handling:
> > > [50598.774763] Call Trace:
> > > [50598.774775]  typec_unregister_partner+0x6c/0x110
> > > [50598.774787]  ucsi_unregister_partner+0x103/0x140
> > > [50598.774794]  ucsi_handle_connector_change+0x34d/0x3e0
> > > [50598.774803]  process_one_work+0x18b/0x340
> > > [50598.774811]  worker_thread+0x256/0x3a0
> > > [50598.774824]  kthread+0xfc/0x240
> > 
> > but that said, I don't see why this would be new behavior. I don't see
> > anything that has changed in this area lately in the typec class
> > handling.
> > 
> > In fact, looking around, I see much older reports that look a bit like
> > this, so I don't think it's new.
> > 
> > Adding Greg and Heikki who might know what is going on. See
> > 
> >    https://lore.kernel.org/all/2203148.PYKUYFuaPT@arborvitaetree/
> > 
> > for original report.
> > 
> >                 Linus
> 
> I really only noticed it when I was looking in dmesg very recently to see if 
> there were any application crashes due to huge_memory issue. I do look in 
> dmesg often enough, but mostly to see if devices are being recognized properly 
> or other events such as when the embedded JVM I am working on split locks.

Thanks for the report. It looks like the code does not increment the
reference count of the USB device that is liked to the typec partner.

Is it possible for you to test this?

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 9b2647cb199b..4ace92af9856 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -805,6 +805,8 @@ static void typec_partner_link_device(struct typec_partner *partner, struct devi
                return;
        }
 
+       get_device(dev);
+
        if (partner->attach)
                partner->attach(partner, dev);
 }
@@ -816,6 +818,8 @@ static void typec_partner_unlink_device(struct typec_partner *partner, struct de
 
        if (partner->deattach)
                partner->deattach(partner, dev);
+
+       put_device(dev);
 }
 
 /**

-- 
heikki