Sockmap cork path double-frees under concurrent TCP sendmsg

A use-after-free in the kernel’s BPF sockmap TCP send path can free a corked message twice when two threads send on the same socket. Chengfeng Ye posted a fix after KASAN caught the double free in sk_msg_free during sendto.

The send path may hold a pointer to the current transmit message across sk_stream_wait_memory, which drops and reacquires the socket lock. On the error path it decided whether that pointer was a stack-local temporary by comparing it with the live cork pointer. A second thread can finish and free the cork while the first is waiting, so the first thread’s stale pointer no longer matches and is treated as local storage and freed again.

The fix stops consulting the shared cork for ownership and frees only when the pointer is the stack temporary. The bug dates to the conversion of sockmap to the generic sk_msg interface and is marked for stable kernels.

Reviewer Emil Tsalapatis backed the change but urged cleaning several related error-path problems in the same function at once, including leaked pages on temporary messages and misreported send lengths. Jakub Sitnicki preferred landing one fix at a time so sockmap selftests stay reviewable. Ye withdrew the broader revisions and said the original single-issue patch should be the basis for further review, with a proper bpf-tree resend so CI runs the sockmap tests.