cve/published/2025/CVE-2025-21642.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2025-21642: mptcp: sysctl: sched: avoid using current->nsproxy

 Description
 ===========

 In the Linux kernel, the following vulnerability has been resolved:

 mptcp: sysctl: sched: avoid using current->nsproxy

 Using the 'net' structure via 'current' is not recommended for different
 reasons.

 First, if the goal is to use it to read or write per-netns data, this is
 inconsistent with how the "generic" sysctl entries are doing: directly
 by only using pointers set to the table entry, e.g. table->data. Linked
 to that, the per-netns data should always be obtained from the table
 linked to the netns it had been created for, which may not coincide with
 the reader's or writer's netns.

 Another reason is that access to current->nsproxy->netns can oops if
 attempted when current->nsproxy had been dropped when the current task
 is exiting. This is what syzbot found, when using acct(2):

   Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI
   KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
   CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0
   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
   RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125
   Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00
   RSP: 0018:ffffc900034774e8 EFLAGS: 00010206

   RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620
   RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028
   RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040
   R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000
   R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000
   FS:  0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    <TASK>
    proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601
    __kernel_write_iter+0x318/0xa80 fs/read_write.c:612
    __kernel_write+0xf6/0x140 fs/read_write.c:632
    do_acct_process+0xcb0/0x14a0 kernel/acct.c:539
    acct_pin_kill+0x2d/0x100 kernel/acct.c:192
    pin_kill+0x194/0x7c0 fs/fs_pin.c:44
    mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81
    cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366
    task_work_run+0x14e/0x250 kernel/task_work.c:239
    exit_task_work include/linux/task_work.h:43 [inline]
    do_exit+0xad8/0x2d70 kernel/exit.c:938
    do_group_exit+0xd3/0x2a0 kernel/exit.c:1087
    get_signal+0x2576/0x2610 kernel/signal.c:3017
    arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337
    exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
    exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
    __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
    syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218
    do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89
    entry_SYSCALL_64_after_hwframe+0x77/0x7f
   RIP: 0033:0x7fee3cb87a6a
   Code: Unable to access opcode bytes at 0x7fee3cb87a40.
   RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037
   RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a
   RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003
   RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7
   R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500
   R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000
    </TASK>
   Modules linked in:
   ---[ end trace 0000000000000000 ]---
   RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125
   Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00
   RSP: 0018:ffffc900034774e8 EFLAGS: 00010206
   RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620
   RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028
   RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040
   R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000
   R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000
   FS:  0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   ----------------
   Code disassembly (best guess), 1 bytes skipped:
      0:	42 80 3c 38 00       	cmpb   $0x0,(%rax,%r15,1)
      5:	0f 85 fe 02 00 00    	jne    0x309
      b:	4d 8b a4 24 08 09 00 	mov    0x908(%r12),%r12
     12:	00
     13:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
     1a:	fc ff df
     1d:	49 8d 7c 24 28       	lea    0x28(%r12),%rdi
     22:	48 89 fa             	mov    %rdi,%rdx
     25:	48 c1 ea 03          	shr    $0x3,%rdx
   * 29:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping instruction
     2d:	0f 85 cc 02 00 00    	jne    0x2ff
     33:	4d 8b 7c 24 28       	mov    0x28(%r12),%r15
     38:	48                   	rex.W
     39:	8d                   	.byte 0x8d
     3a:	84 24 c8             	test   %ah,(%rax,%rcx,8)

 Here with 'net.mptcp.scheduler', the 'net' structure is not really
 needed, because the table->data already has a pointer to the current
 scheduler, the only thing needed from the per-netns data.
 Simply use 'data', instead of getting (most of the time) the same thing,
 but from a longer and indirect way.

 The Linux kernel CVE team has assigned CVE-2025-21642 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 6.6.31 with commit daad878a509d69da1761106cb48c091dfe9d522d and fixed in 6.6.72 with commit c0e394fd6b887e84da17e38aaa6c1c104f9c86c2
 	Issue introduced in 6.9 with commit 6963c508fd7ab66ae0b7ae3db9a62ca6267f1ae8 and fixed in 6.12.10 with commit 6035702381c35a8f16757332381e58b348a9eaf9
 	Issue introduced in 6.9 with commit 6963c508fd7ab66ae0b7ae3db9a62ca6267f1ae8 and fixed in 6.13 with commit d38e26e36206ae3d544d496513212ae931d1da0a
 	Issue introduced in 6.8.10 with commit 1e444f5f2a07844354ad767b44ed0a713211e26d

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2025-21642
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	net/mptcp/ctrl.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/c0e394fd6b887e84da17e38aaa6c1c104f9c86c2
 	https://git.kernel.org/stable/c/6035702381c35a8f16757332381e58b348a9eaf9
 	https://git.kernel.org/stable/c/d38e26e36206ae3d544d496513212ae931d1da0a
	From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2025-21642: mptcp: sysctl: sched: avoid using current->nsproxy

	Description
	===========

	In the Linux kernel, the following vulnerability has been resolved:

	mptcp: sysctl: sched: avoid using current->nsproxy

	Using the 'net' structure via 'current' is not recommended for different
	reasons.

	First, if the goal is to use it to read or write per-netns data, this is
	inconsistent with how the "generic" sysctl entries are doing: directly
	by only using pointers set to the table entry, e.g. table->data. Linked
	to that, the per-netns data should always be obtained from the table
	linked to the netns it had been created for, which may not coincide with
	the reader's or writer's netns.

	Another reason is that access to current->nsproxy->netns can oops if
	attempted when current->nsproxy had been dropped when the current task
	is exiting. This is what syzbot found, when using acct(2):

	Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI
	KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
	CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0
	Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
	RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125
	Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00
	RSP: 0018:ffffc900034774e8 EFLAGS: 00010206

	RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620
	RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028
	RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040
	R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000
	R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000
	FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
	CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0
	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
	Call Trace:
	<TASK>
	proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601
	__kernel_write_iter+0x318/0xa80 fs/read_write.c:612
	__kernel_write+0xf6/0x140 fs/read_write.c:632
	do_acct_process+0xcb0/0x14a0 kernel/acct.c:539
	acct_pin_kill+0x2d/0x100 kernel/acct.c:192
	pin_kill+0x194/0x7c0 fs/fs_pin.c:44
	mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81
	cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366
	task_work_run+0x14e/0x250 kernel/task_work.c:239
	exit_task_work include/linux/task_work.h:43 [inline]
	do_exit+0xad8/0x2d70 kernel/exit.c:938
	do_group_exit+0xd3/0x2a0 kernel/exit.c:1087
	get_signal+0x2576/0x2610 kernel/signal.c:3017
	arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337
	exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
	exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
	__syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
	syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218
	do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89
	entry_SYSCALL_64_after_hwframe+0x77/0x7f
	RIP: 0033:0x7fee3cb87a6a
	Code: Unable to access opcode bytes at 0x7fee3cb87a40.
	RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037
	RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a
	RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003
	RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7
	R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500
	R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000
	</TASK>
	Modules linked in:
	---[ end trace 0000000000000000 ]---
	RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125
	Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00
	RSP: 0018:ffffc900034774e8 EFLAGS: 00010206
	RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620
	RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028
	RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040
	R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000
	R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000
	FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
	CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0
	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
	----------------
	Code disassembly (best guess), 1 bytes skipped:
	0: 42 80 3c 38 00 cmpb $0x0,(%rax,%r15,1)
	5: 0f 85 fe 02 00 00 jne 0x309
	b: 4d 8b a4 24 08 09 00 mov 0x908(%r12),%r12
	12: 00
	13: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax
	1a: fc ff df
	1d: 49 8d 7c 24 28 lea 0x28(%r12),%rdi
	22: 48 89 fa mov %rdi,%rdx
	25: 48 c1 ea 03 shr $0x3,%rdx
	* 29: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction
	2d: 0f 85 cc 02 00 00 jne 0x2ff
	33: 4d 8b 7c 24 28 mov 0x28(%r12),%r15
	38: 48 rex.W
	39: 8d .byte 0x8d
	3a: 84 24 c8 test %ah,(%rax,%rcx,8)

	Here with 'net.mptcp.scheduler', the 'net' structure is not really
	needed, because the table->data already has a pointer to the current
	scheduler, the only thing needed from the per-netns data.
	Simply use 'data', instead of getting (most of the time) the same thing,
	but from a longer and indirect way.

	The Linux kernel CVE team has assigned CVE-2025-21642 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 6.6.31 with commit daad878a509d69da1761106cb48c091dfe9d522d and fixed in 6.6.72 with commit c0e394fd6b887e84da17e38aaa6c1c104f9c86c2
	Issue introduced in 6.9 with commit 6963c508fd7ab66ae0b7ae3db9a62ca6267f1ae8 and fixed in 6.12.10 with commit 6035702381c35a8f16757332381e58b348a9eaf9
	Issue introduced in 6.9 with commit 6963c508fd7ab66ae0b7ae3db9a62ca6267f1ae8 and fixed in 6.13 with commit d38e26e36206ae3d544d496513212ae931d1da0a
	Issue introduced in 6.8.10 with commit 1e444f5f2a07844354ad767b44ed0a713211e26d

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-21642
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	net/mptcp/ctrl.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/c0e394fd6b887e84da17e38aaa6c1c104f9c86c2
	https://git.kernel.org/stable/c/6035702381c35a8f16757332381e58b348a9eaf9
	https://git.kernel.org/stable/c/d38e26e36206ae3d544d496513212ae931d1da0a