diff options
author | Marco Elver <elver@google.com> | 2021-02-09 14:27:01 +0300 |
---|---|---|
committer | Andrii Nakryiko <andrii@kernel.org> | 2021-02-11 02:54:26 +0300 |
commit | 6df8fb83301d68ea0a0c0e1cbcc790fcc333ed12 (patch) | |
tree | d4cd79c6a35d0322e2f7a903c58a7c314b742fd7 /include/linux/filter.h | |
parent | bd2d4e6c6e9f0186967252e8c7ab29a23c3db9cf (diff) | |
download | linux-6df8fb83301d68ea0a0c0e1cbcc790fcc333ed12.tar.xz |
bpf_lru_list: Read double-checked variable once without lock
For double-checked locking in bpf_common_lru_push_free(), node->type is
read outside the critical section and then re-checked under the lock.
However, concurrent writes to node->type result in data races.
For example, the following concurrent access was observed by KCSAN:
write to 0xffff88801521bc22 of 1 bytes by task 10038 on cpu 1:
__bpf_lru_node_move_in kernel/bpf/bpf_lru_list.c:91
__local_list_flush kernel/bpf/bpf_lru_list.c:298
...
read to 0xffff88801521bc22 of 1 bytes by task 10043 on cpu 0:
bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:507
bpf_lru_push_free kernel/bpf/bpf_lru_list.c:555
...
Fix the data races where node->type is read outside the critical section
(for double-checked locking) by marking the access with READ_ONCE() as
well as ensuring the variable is only accessed once.
Fixes: 3a08c2fd7634 ("bpf: LRU List")
Reported-by: syzbot+3536db46dfa58c573458@syzkaller.appspotmail.com
Reported-by: syzbot+516acdb03d3e27d91bcd@syzkaller.appspotmail.com
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20210209112701.3341724-1-elver@google.com
Diffstat (limited to 'include/linux/filter.h')
0 files changed, 0 insertions, 0 deletions