For more on why MPTCP is not relevant--my limited understanding is the issue is with SYN retransmits.

SYN packet #1 is received and added to a request queue for processing.

SYN packet #2 is received and is a retransmit of SYN packet #1. It is matched to SYN packet #1 already in the request queue and now there is shared state between both SYN packets #1 and #2 in the request queue.

CPU #1 takes on the task of processing SYN packet #1.

CPU #2 takes on the task of processing SYN packet #2.

CPU #1 responds back with RST packet #1 (e.g. requested TCP port is not open) and _should_ defer the destruction of the request socket for SYN packet #1, as other CPUs may still be processing the shared state for the request socket as is the case for retransmitted SYN packets.[1] However, this deferred destruction wasn't occurring, and CPU #1 was _immediately_ destroying the request socket/shared state for SYN packet #1.

CPU #2 races with CPU #1 and reads from the request socket/shared state for SYN packet #1 after its _immediate_ destruction by CPU #1.

Linux's IPv6 handling is unaffected because in this IPv6 scenario, there is no shared state between SYN packets #1 and #2 in the request queue. Instead, each request socket has duplicate data.

Someone more knowledgeable can confirm/correct me on the above please.

[1] https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html#rc...