Re: [PATCH net v2] udp: revalidate socket family before publishing an IPv6 cork

[Paolo Abeni <pabeni@redhat.com>]

On 8/29/26 3:21 PM, Daehyeon Ko wrote:
> udpv6_sendmsg() prepares the IPv6 flow and route before taking the socket
> lock when a datagram is corked.  IPV6_ADDRFORM takes the same lock, but it
> can convert the socket to AF_INET while the send path is doing that
> lockless preparation because no cork has been published yet.
> 
> If the conversion wins the race, udpv6_sendmsg() later publishes an
> AF_INET6 cork on an AF_INET socket.  Uncorking through the IPv4 socket
> operations then interprets the IPv6 cork as IPv4 state.  The IPv4
> finalizer writes a 20-byte IPv4 header into the 40-byte IPv6 header
> reservation while the retained IPv6 dst routes the skb through
> ip6_output().  ip6_finish_output2() consequently consumes the unwritten
> 20-byte tail.
> 
> An unprivileged reproducer triggered the mixed state on 12 of 10,000
> sockets.  KMSAN reported an uninitialized-value read in
> ip6_finish_output2() on three fresh boots, with the allocation origin in
> __alloc_skb() through __ip6_append_data().  The same process recovered the
> 20-byte region from the TX timestamp error queue; one of three fresh boots
> contained recognizable stale heap data.
> 
> The route prepared by the racing send is not published in the socket dst
> cache.  An implicit send on the IPv4-mapped peer required by ADDRFORM
> delegates to udp_sendmsg() before the IPv6 lookup.  An explicit native IPv6
> destination reaches the lookup, but leaves connected false and therefore
> cannot call ip6_sk_dst_store_flow().  Conversely, a native connected send
> can publish an IPv6 dst, but ADDRFORM rejects that peer with EADDRNOTAVAIL.
> The same reasoning covers the non-corking explicit send path.
> 
> After taking the lock, revalidate that IPV6_ADDRFORM has not changed the
> socket family before publishing the cork.  The existing error path releases
> the invocation's prepared dst, flowlabel, and transmit-option references;
> there is no socket dst cache entry from this send to reset.  With this
> change, the serialized controls retain their existing results and the
> forbidden mixed state occurred zero times across 20,000 sockets.

I understand that with the above you intend address sashiko concerns
WRT cached dst:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260829132125.1160893-1-4ncienth%40gmail.com

but I tend to agree with sashiko that the race is still present.

/P