linux-kernel - RFC: Switch namespaces before upcall

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

Message-ID: <CANT5p=orw4u7rSOQtAZap4Kerq_x3w=QneFWhBrXec26xvdycQ@mail.gmail.com>
Date: Sun, 26 Oct 2025 23:31:31 +0530
From: Shyam Prasad N <nspmangalore@...il.com>
To: David Howells <dhowells@...hat.com>, brauner@...nel.org, 
	Steve French <smfrench@...il.com>, keyrings@...r.kernel.org, 
	CIFS <linux-cifs@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: RFC: Switch namespaces before upcall

Hi David / Christian,

I've been trying to make changes in the kernel to allow keys to switch
namespaces before making the upcall using the UMH code in the kernel.
The kernel keys subsystem lacks this ability today, forcing the upcall
handlers to first switch namespaces using setns call, and then do the
handling. But for many container based environments, this is a serious
inconvenience.

In an attempt to get this to work, I've needed to export some
functions in nsproxy.c, which were earlier static. Now, it looks to me
like it's tripping in some part of namespace installation, which I'm
unable to decode. Could you please help me with this?

-----------------------------------------
[Sun Oct 26 17:01:03 2025] Key type cifs.spnego registered
[Sun Oct 26 17:01:03 2025] Key type cifs.idmap registered
[Sun Oct 26 17:01:03 2025] CIFS: No dialect specified on mount.
Default has changed to a more secure dialect, SMB2.1 or later (e.g.
SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to
access ol
d servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1)
specify vers=1.0 on mount.
[Sun Oct 26 17:01:03 2025] CIFS: Attempting to mount //192.168.122.1/testshare
[Sun Oct 26 17:01:04 2025] CIFS: VFS: unknown or missing server auth
type, use krb5
[Sun Oct 26 17:01:04 2025]
==================================================================
[Sun Oct 26 17:01:04 2025] BUG: KASAN: null-ptr-deref in
current_is_single_threaded+0xea/0x570
[Sun Oct 26 17:01:04 2025] Read of size 4 at addr 00000000000000cc by
task kworker/u91:0/1570

[Sun Oct 26 17:01:04 2025] CPU: 18 UID: 0 PID: 1570 Comm:
kworker/u91:0 Not tainted 6.17.0-rc6-nsupcall #26 PREEMPT(voluntary)
[Sun Oct 26 17:01:04 2025] Hardware name: QEMU Standard PC (Q35 +
ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[Sun Oct 26 17:01:04 2025] Call Trace:
[Sun Oct 26 17:01:04 2025]  <TASK>
[Sun Oct 26 17:01:04 2025]  dump_stack_lvl+0x91/0xf0
[Sun Oct 26 17:01:04 2025]  print_report+0x442/0x660
[Sun Oct 26 17:01:04 2025]  ? lock_acquired+0x196/0x3a0
[Sun Oct 26 17:01:04 2025]  ? kasan_addr_to_slab+0xd/0xb0
[Sun Oct 26 17:01:04 2025]  kasan_report+0xf3/0x130
[Sun Oct 26 17:01:04 2025]  ? current_is_single_threaded+0xea/0x570
[Sun Oct 26 17:01:04 2025]  ? current_is_single_threaded+0xea/0x570
[Sun Oct 26 17:01:04 2025]  kasan_check_range+0x11c/0x200
[Sun Oct 26 17:01:04 2025]  __kasan_check_read+0x11/0x20
[Sun Oct 26 17:01:04 2025]  current_is_single_threaded+0xea/0x570
[Sun Oct 26 17:01:04 2025]  ? security_capable+0x77/0x1c0
[Sun Oct 26 17:01:04 2025]  timens_install+0x48/0x340
[Sun Oct 26 17:01:04 2025]  ? netns_install+0x141/0x210
[Sun Oct 26 17:01:04 2025]  validate_nsset+0x4b8/0xc60
[Sun Oct 26 17:01:04 2025]  umh_keys_init+0x23e/0x340
[Sun Oct 26 17:01:04 2025]  ? kvm_sched_clock_read+0x11/0x20
[Sun Oct 26 17:01:04 2025]  ? __pfx_umh_keys_init+0x10/0x10
[Sun Oct 26 17:01:04 2025]  ? local_clock_noinstr+0xe/0xd0
[Sun Oct 26 17:01:04 2025]  ? do_raw_spin_unlock+0x14b/0x200
[Sun Oct 26 17:01:04 2025]  call_usermodehelper_exec_async+0x1c3/0x470
[Sun Oct 26 17:01:04 2025]  ? __pfx_call_usermodehelper_exec_async+0x10/0x10
[Sun Oct 26 17:01:04 2025]  ret_from_fork+0x3ed/0x540
[Sun Oct 26 17:01:04 2025]  ? __pfx_call_usermodehelper_exec_async+0x10/0x10
[Sun Oct 26 17:01:04 2025]  ret_from_fork_asm+0x1a/0x30
[Sun Oct 26 17:01:04 2025]  </TASK>
[Sun Oct 26 17:01:04 2025]
==================================================================
-----------------------------------------

Could it be because the process that is attempting to do
validate_nsset is a kernel tsk and not a userspace process? If so, is
there any easy way to work around this to get the solution working?

Thanks in advance.

-- 
Regards,
Shyam

Download attachment "c05f8636e3f00f93ede37e79cdb4b7bb308a1bb2.patch" of type "application/octet-stream" (9489 bytes)

Download attachment "75bd1ccaaaf9a42840df293e45e49436797b1bca.patch" of type "application/octet-stream" (8496 bytes)