Re: [PATCH v3] skbuff: fix a data race in skb_queue_len()

David Miller
2020-02-06T12:59:29Z

From: Qian Cai <cai@lca.pw>
Date: Tue, 4 Feb 2020 13:40:29 -0500

> sk_buff.qlen can be accessed concurrently as noticed by KCSAN,
>
> BUG: KCSAN: data-race in __skb_try_recv_from_queue / unix_dgram_sendmsg
>
> read to 0xffff8a1b1d8a81c0 of 4 bytes by task 5371 on cpu 96:
> unix_dgram_sendmsg+0x9a9/0xb70 include/linux/skbuff.h:1821
> net/unix/af_unix.c:1761
> ____sys_sendmsg+0x33e/0x370
> ___sys_sendmsg+0xa6/0xf0
> __sys_sendmsg+0x69/0xf0
> __x64_sys_sendmsg+0x51/0x70
> do_syscall_64+0x91/0xb47
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> write to 0xffff8a1b1d8a81c0 of 4 bytes by task 1 on cpu 99:
> __skb_try_recv_from_queue+0x327/0x410 include/linux/skbuff.h:2029
> __skb_try_recv_datagram+0xbe/0x220
> unix_dgram_recvmsg+0xee/0x850
> ____sys_recvmsg+0x1fb/0x210
> ___sys_recvmsg+0xa2/0xf0
> __sys_recvmsg+0x66/0xf0
> __x64_sys_recvmsg+0x51/0x70
> do_syscall_64+0x91/0xb47
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Since only the read is operating as lockless, it could introduce a logic
> bug in unix_recvq_full() due to the load tearing. Fix it by adding
> a lockless variant of skb_queue_len() and unix_recvq_full() where
> READ_ONCE() is on the read while WRITE_ONCE() is on the write similar to
> the commit d7d16a89350a ("net: add skb_queue_empty_lockless()").
>
> Signed-off-by: Qian Cai <cai@lca.pw>

Applied, thank you.