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: <CAHk-=wiaNtXHghUS_cixm8i-Vfq1=9n_2DFJ-+bB-thpQHStgA@mail.gmail.com>
Date: Tue, 18 Nov 2025 10:01:54 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Stephanie Gawroriski <xerthesquirrel@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Subject: Re: Linux 6.18-rc6

On Tue, 18 Nov 2025 at 09:23, Stephanie Gawroriski
<xerthesquirrel@...il.com> wrote:
>
> Since rc6 I am getting crashes in JetBrain's Rider backend for CLion, which
> the backend is a C# application specifically, which gives in its logs:

Yeah, that looks like the same bug that David Wang and some other
people reported.

Can you check current top-of-tree, which includes that commit
5bebe8de1926 ("mm/huge_memory: Fix initialization of huge zero folio")
which hopefully fixes this for you.

> Unfortunately, I do not see any traces in `dmesg` at all and there is not much
> else useful there.

Yeah, that bug would only confuse user space due to an uninitialized
memory area, the kernel itself would be unaffected and wouldn't see
anything wrong (apart from then possibly killing misbehaving apps due
to the confusion).

> Unlike David Wang, I am on an Intel Core i7-1370P on a ThinkPad X1 Yoga
> Gen 8 (with TME) and I have not experienced any crashes with GDB or Go in any
> way, nor other program issues at all.

It's going to be a bit random, because that huge zero-page ends up
being used by some loads but not all. I think David Wang also reported
that it only happened for particular versions for him.

> 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?

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