CVE-2025-21938

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.