Re: [PATCH net] net: initialize sk_rx_queue_mapping in sk_clone()

[Eric Dumazet]

On Tue, Apr 7, 2026 at 1:43 AM Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
>
> sk_clone() initializes sk_tx_queue_mapping via sk_tx_queue_clear()
> but does not initialize sk_rx_queue_mapping. Since this field is in
> the sk_dontcopy region, it is neither copied from the parent socket
> by sock_copy() nor zeroed by sk_prot_alloc() (called without
> __GFP_ZERO from sk_clone).
>
> Commit 03cfda4fa6ea ("tcp: fix another uninit-value
> (sk_rx_queue_mapping)") attempted to fix this by introducing
> sk_mark_napi_id_set() with force_set=true in tcp_child_process().
> However, sk_mark_napi_id_set() -> sk_rx_queue_set() only writes
> when skb_rx_queue_recorded(skb) is true. If the 3-way handshake
> ACK arrives through a device that does not record rx_queue (e.g.
> loopback or veth), sk_rx_queue_mapping remains uninitialized.
>
> When a subsequent data packet arrives with a recorded rx_queue,
> sk_mark_napi_id() -> sk_rx_queue_update() reads the uninitialized
> field for comparison (force_set=false path), triggering KMSAN.
>
> This was reproduced by establishing a TCP connection over loopback
> (which does not call skb_record_rx_queue), then attaching a BPF TC
> program on lo ingress to set skb->queue_mapping on data packets:

Ok, it's a somewhat convoluted way, and no real harm but KMSAN :)

Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>