Files
linux/include/linux
Qian Cai adfed4eee6 skbuff: fix a data race in skb_queue_len()
[ Upstream commit 86b18aaa2b ]

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 d7d16a8935 ("net: add skb_queue_empty_lockless()").

Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-16 09:15:28 +09:00
..
2023-04-21 13:52:38 +09:00
2015-10-07 18:08:15 +01:00
2016-07-08 16:23:11 +02:00
2023-05-15 17:28:23 +09:00
2016-08-25 11:26:48 -04:00
2017-10-08 10:26:06 +02:00
2018-04-24 09:34:18 +02:00
2018-04-12 09:54:41 -07:00
2018-02-28 10:18:33 +01:00
2018-05-30 13:19:56 +02:00
2016-06-07 13:41:38 -06:00
2016-05-17 15:48:12 -04:00
2018-04-12 09:54:41 -07:00
2023-05-15 15:11:10 +09:00
2017-07-12 15:01:02 +02:00
2017-12-10 17:13:13 +01:00
2023-05-16 08:57:37 +09:00
2018-04-12 09:54:41 -07:00
2023-05-15 17:11:10 +09:00
2018-03-14 20:21:31 -08:00
2016-07-22 09:07:02 +02:00
2016-09-24 10:48:18 +02:00
2015-11-25 09:22:00 -07:00
2016-02-11 09:59:22 -05:00
2018-04-09 11:39:17 -07:00
2016-10-20 15:51:28 +11:00
2016-09-16 09:34:15 +01:00
2016-09-14 09:18:09 -06:00
2018-01-02 20:45:15 +01:00
2016-05-11 22:37:54 +02:00
2015-06-25 12:06:45 +02:00
2016-01-28 14:19:12 -08:00
2023-05-15 08:33:22 +09:00
2016-08-10 11:23:44 -04:00
2017-10-30 09:27:09 +01:00
2016-03-22 15:36:02 -07:00
2015-07-28 08:50:42 +01:00
2023-05-15 17:12:36 +09:00
2016-01-15 17:56:32 -08:00
2016-09-15 16:49:39 +02:00
2016-09-27 12:33:47 +02:00
2017-08-24 17:12:19 -07:00
2018-04-17 17:58:08 -08:00
2015-06-24 17:49:41 -07:00
2015-07-21 10:39:05 -07:00
2016-04-25 15:09:11 -04:00
2016-02-16 13:04:58 -05:00
2016-10-19 11:36:22 -06:00
2016-05-02 09:00:56 -05:00
2018-03-22 09:54:47 +01:00
2016-02-11 18:35:48 -08:00
2016-03-14 15:43:11 -04:00
2023-05-15 17:09:21 +09:00
2017-08-24 17:12:21 -07:00
2016-10-14 11:36:59 -07:00
2016-07-12 19:25:38 -07:00
2016-09-27 21:52:00 -04:00
2016-09-08 15:01:10 -07:00
2016-03-17 15:09:34 -07:00
2016-07-06 10:51:14 +01:00
2016-03-22 15:36:02 -07:00
2016-07-26 16:19:19 -07:00
2016-09-08 22:15:25 -07:00
2023-05-15 17:14:27 +09:00
2023-05-15 17:12:28 +09:00
2017-08-30 10:21:40 +02:00
2016-08-28 23:44:55 -04:00
2016-10-05 18:23:36 -04:00
2023-05-15 12:21:56 +09:00
2018-05-30 13:19:56 +02:00
2023-05-15 09:23:01 +09:00
2017-03-17 13:14:32 +08:00
2015-10-01 09:57:59 -07:00
2016-07-19 17:43:38 +03:00
2023-05-15 17:27:48 +09:00
2016-05-23 17:04:14 -07:00
2016-04-07 16:53:29 -04:00
2017-04-21 09:31:21 +02:00
2015-11-23 09:44:58 +01:00
2016-07-26 16:19:19 -07:00
2016-05-20 17:58:30 -07:00
2017-12-25 14:23:37 +01:00
2018-04-03 17:37:41 -08:00
2023-05-15 17:12:32 +09:00
2016-09-30 10:54:03 +02:00
2015-12-03 07:24:29 -08:00
2023-05-15 10:05:34 +09:00
2015-09-08 15:35:28 -07:00