CVE-2025-21938: mptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr

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

mptcp: fix 'scheduling while atomic' in mptcppmnlappendnewlocaladdr

If multiple connection requests attempt to create an implicit mptcp endpoint in parallel, more than one caller may end up in mptcppmnlappendnewlocaladdr because none found the address in localaddrlist during their call to mptcppmnlgetlocalid. In this case, the concurrent newlocaladdr calls may delete the address entry created by the previous caller. These deletes use synchronizercu, 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> dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) dumpstack (lib/dumpstack.c:124) schedulebug (kernel/sched/core.c:5943) scheduledebug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970) schedule (arch/x86/include/asm/jumplabel.h:27 include/linux/jumplabel.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) scheduletimeout (kernel/time/timer.c:2160) waitforcompletion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148) waitrcugp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444) synchronizercu (kernel/rcu/tree.c:3609) mptcppmnlappendnewlocaladdr (net/mptcp/pmnetlink.c:966 net/mptcp/pmnetlink.c:1061) mptcppmnlgetlocalid (net/mptcp/pmnetlink.c:1164) mptcppmgetlocalid (net/mptcp/pm.c:420) subflowcheckreq (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflowv4routereq (net/mptcp/subflow.c:305) tcpconnrequest (net/ipv4/tcpinput.c:7216) subflowv4connrequest (net/mptcp/subflow.c:651) tcprcvstateprocess (net/ipv4/tcpinput.c:6709) tcpv4dorcv (net/ipv4/tcpipv4.c:1934) tcpv4rcv (net/ipv4/tcpipv4.c:2334) ipprotocoldeliverrcu (net/ipv4/ipinput.c:205 (discriminator 1)) iplocaldeliverfinish (include/linux/rcupdate.h:813 net/ipv4/ipinput.c:234) iplocaldeliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ipinput.c:254) ipsublistrcvfinish (include/net/dst.h:461 net/ipv4/ipinput.c:580) ipsublistrcv (net/ipv4/ipinput.c:640) iplistrcv (net/ipv4/ipinput.c:675) netifreceiveskblistcore (net/core/dev.c:5583 net/core/dev.c:5631) netifreceiveskblistinternal (net/core/dev.c:5685 net/core/dev.c:5774) napicompletedone (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114) igbpoll (drivers/net/ethernet/intel/igb/igbmain.c:8244) igb napipoll (net/core/dev.c:6582) netrxaction (net/core/dev.c:6653 net/core/dev.c:6787) handlesoftirqs (kernel/softirq.c:553) irqexitrcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636) irqexitrcu (kernel/softirq.c:651) commoninterrupt (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 localaddrlist entries which have the internal address instead.

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