CVE-2025-21938

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix &amp;#39;scheduling while atomic&amp;#39; in mptcp_pm_nl_append_new_local_addr<br /> <br /> If multiple connection requests attempt to create an implicit mptcp<br /> endpoint in parallel, more than one caller may end up in<br /> mptcp_pm_nl_append_new_local_addr because none found the address in<br /> local_addr_list during their call to mptcp_pm_nl_get_local_id. In this<br /> case, the concurrent new_local_addr calls may delete the address entry<br /> created by the previous caller. These deletes use synchronize_rcu, but<br /> this is not permitted in some of the contexts where this function may be<br /> called. During packet recv, the caller may be in a rcu read critical<br /> section and have preemption disabled.<br /> <br /> An example stack:<br /> <br /> BUG: scheduling while atomic: swapper/2/0/0x00000302<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))<br /> dump_stack (lib/dump_stack.c:124)<br /> __schedule_bug (kernel/sched/core.c:5943)<br /> schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)<br /> __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)<br /> schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)<br /> schedule_timeout (kernel/time/timer.c:2160)<br /> wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)<br /> __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)<br /> synchronize_rcu (kernel/rcu/tree.c:3609)<br /> mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)<br /> mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)<br /> mptcp_pm_get_local_id (net/mptcp/pm.c:420)<br /> subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)<br /> subflow_v4_route_req (net/mptcp/subflow.c:305)<br /> tcp_conn_request (net/ipv4/tcp_input.c:7216)<br /> subflow_v4_conn_request (net/mptcp/subflow.c:651)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)<br /> tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)<br /> tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)<br /> ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))<br /> ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)<br /> ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)<br /> ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)<br /> ip_sublist_rcv (net/ipv4/ip_input.c:640)<br /> ip_list_rcv (net/ipv4/ip_input.c:675)<br /> __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)<br /> netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)<br /> napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)<br /> igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb<br /> __napi_poll (net/core/dev.c:6582)<br /> net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)<br /> handle_softirqs (kernel/softirq.c:553)<br /> __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)<br /> irq_exit_rcu (kernel/softirq.c:651)<br /> common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))<br /> <br /> <br /> This problem seems particularly prevalent if the user advertises an<br /> endpoint that has a different external vs internal address. In the case<br /> where the external address is advertised and multiple connections<br /> already exist, multiple subflow SYNs arrive in parallel which tends to<br /> trigger the race during creation of the first local_addr_list entries<br /> which have the internal address instead.<br /> <br /> Fix by skipping the replacement of an existing implicit local address if<br /> called via mptcp_pm_nl_get_local_id.