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

 From bippy-7c5fe7eed585 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-21938: mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr

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

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

 mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr

 If multiple connection requests attempt to create an implicit mptcp
 endpoint in parallel, more than one caller may end up in
 mptcp_pm_nl_append_new_local_addr because none found the address in
 local_addr_list during their call to mptcp_pm_nl_get_local_id.  In this
 case, the concurrent new_local_addr calls may delete the address entry
 created by the previous caller.  These deletes use synchronize_rcu, but
 this is not permitted in some of the contexts where this function may be
 called.  During packet recv, the caller may be in a rcu read critical
 section and have preemption disabled.

 An example stack:

    BUG: scheduling while atomic: swapper/2/0/0x00000302

    Call Trace:
    <IRQ>
    dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))
    dump_stack (lib/dump_stack.c:124)
    __schedule_bug (kernel/sched/core.c:5943)
    schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)
    __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)
    schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)
    schedule_timeout (kernel/time/timer.c:2160)
    wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)
    __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)
    synchronize_rcu (kernel/rcu/tree.c:3609)
    mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)
    mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)
    mptcp_pm_get_local_id (net/mptcp/pm.c:420)
    subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)
    subflow_v4_route_req (net/mptcp/subflow.c:305)
    tcp_conn_request (net/ipv4/tcp_input.c:7216)
    subflow_v4_conn_request (net/mptcp/subflow.c:651)
    tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)
    tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)
    tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)
    ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))
    ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)
    ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)
    ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)
    ip_sublist_rcv (net/ipv4/ip_input.c:640)
    ip_list_rcv (net/ipv4/ip_input.c:675)
    __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)
    netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)
    napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)
    igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582)
    net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)
    handle_softirqs (kernel/softirq.c:553)
    __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)
    irq_exit_rcu (kernel/softirq.c:651)
    common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))
    </IRQ>

 This problem seems particularly prevalent if the user advertises an
 endpoint that has a different external vs internal address.  In the case
 where the external address is advertised and multiple connections
 already exist, multiple subflow SYNs arrive in parallel which tends to
 trigger the race during creation of the first local_addr_list entries
 which have the internal address instead.

 Fix by skipping the replacement of an existing implicit local address if
 called via mptcp_pm_nl_get_local_id.

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


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

 	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.1.131 with commit f1404f368c40fc6a068dad72e4ee0824ee6a78ee
 	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.6.83 with commit f3fcdb2de9fdbed9d8c6a8eb2c5fbd7d6f54a4d8
 	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.12.19 with commit 4b228dae3d2cc6d9dce167449cd8fa9f028e9376
 	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.13.7 with commit 125ccafe6dd062901b5a0c31ee9038740fc8859e
 	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.14 with commit 022bfe24aad8937705704ff2e414b100cf0f2e1a

 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-21938
 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/pm_netlink.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/f1404f368c40fc6a068dad72e4ee0824ee6a78ee
 	https://git.kernel.org/stable/c/f3fcdb2de9fdbed9d8c6a8eb2c5fbd7d6f54a4d8
 	https://git.kernel.org/stable/c/4b228dae3d2cc6d9dce167449cd8fa9f028e9376
 	https://git.kernel.org/stable/c/125ccafe6dd062901b5a0c31ee9038740fc8859e
 	https://git.kernel.org/stable/c/022bfe24aad8937705704ff2e414b100cf0f2e1a
	From bippy-7c5fe7eed585 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-21938: mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr

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

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

	mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr

	If multiple connection requests attempt to create an implicit mptcp
	endpoint in parallel, more than one caller may end up in
	mptcp_pm_nl_append_new_local_addr because none found the address in
	local_addr_list during their call to mptcp_pm_nl_get_local_id. In this
	case, the concurrent new_local_addr calls may delete the address entry
	created by the previous caller. These deletes use synchronize_rcu, but
	this is not permitted in some of the contexts where this function may be
	called. During packet recv, the caller may be in a rcu read critical
	section and have preemption disabled.

	An example stack:

	BUG: scheduling while atomic: swapper/2/0/0x00000302

	Call Trace:
	<IRQ>
	dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))
	dump_stack (lib/dump_stack.c:124)
	__schedule_bug (kernel/sched/core.c:5943)
	schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)
	__schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)
	schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)
	schedule_timeout (kernel/time/timer.c:2160)
	wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)
	__wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)
	synchronize_rcu (kernel/rcu/tree.c:3609)
	mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)
	mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)
	mptcp_pm_get_local_id (net/mptcp/pm.c:420)
	subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)
	subflow_v4_route_req (net/mptcp/subflow.c:305)
	tcp_conn_request (net/ipv4/tcp_input.c:7216)
	subflow_v4_conn_request (net/mptcp/subflow.c:651)
	tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)
	tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)
	tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)
	ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))
	ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)
	ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)
	ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)
	ip_sublist_rcv (net/ipv4/ip_input.c:640)
	ip_list_rcv (net/ipv4/ip_input.c:675)
	__netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)
	netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)
	napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)
	igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
	__napi_poll (net/core/dev.c:6582)
	net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)
	handle_softirqs (kernel/softirq.c:553)
	__irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)
	irq_exit_rcu (kernel/softirq.c:651)
	common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))
	</IRQ>

	This problem seems particularly prevalent if the user advertises an
	endpoint that has a different external vs internal address. In the case
	where the external address is advertised and multiple connections
	already exist, multiple subflow SYNs arrive in parallel which tends to
	trigger the race during creation of the first local_addr_list entries
	which have the internal address instead.

	Fix by skipping the replacement of an existing implicit local address if
	called via mptcp_pm_nl_get_local_id.

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


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

	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.1.131 with commit f1404f368c40fc6a068dad72e4ee0824ee6a78ee
	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.6.83 with commit f3fcdb2de9fdbed9d8c6a8eb2c5fbd7d6f54a4d8
	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.12.19 with commit 4b228dae3d2cc6d9dce167449cd8fa9f028e9376
	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.13.7 with commit 125ccafe6dd062901b5a0c31ee9038740fc8859e
	Issue introduced in 5.18 with commit d045b9eb95a9b611c483897a69e7285aefdc66d7 and fixed in 6.14 with commit 022bfe24aad8937705704ff2e414b100cf0f2e1a

	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-21938
	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/pm_netlink.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/f1404f368c40fc6a068dad72e4ee0824ee6a78ee
	https://git.kernel.org/stable/c/f3fcdb2de9fdbed9d8c6a8eb2c5fbd7d6f54a4d8
	https://git.kernel.org/stable/c/4b228dae3d2cc6d9dce167449cd8fa9f028e9376
	https://git.kernel.org/stable/c/125ccafe6dd062901b5a0c31ee9038740fc8859e
	https://git.kernel.org/stable/c/022bfe24aad8937705704ff2e414b100cf0f2e1a