diff options
author | Daniel Borkmann <daniel@iogearbox.net> | 2017-12-12 02:25:30 +0100 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2017-12-12 09:51:12 -0800 |
commit | 283ca526a9bd75aed7350220d7b1f8027d99c3fd (patch) | |
tree | e702c33467d5fc7b2c3b807addc3269774b9f40c /arch | |
parent | 30791ac41927ebd3e75486f9504b6d2280463bf0 (diff) | |
download | linux-stable-283ca526a9bd75aed7350220d7b1f8027d99c3fd.tar.gz linux-stable-283ca526a9bd75aed7350220d7b1f8027d99c3fd.tar.bz2 linux-stable-283ca526a9bd75aed7350220d7b1f8027d99c3fd.zip |
bpf: fix corruption on concurrent perf_event_output calls
When tracing and networking programs are both attached in the
system and both use event-output helpers that eventually call
into perf_event_output(), then we could end up in a situation
where the tracing attached program runs in user context while
a cls_bpf program is triggered on that same CPU out of softirq
context.
Since both rely on the same per-cpu perf_sample_data, we could
potentially corrupt it. This can only ever happen in a combination
of the two types; all tracing programs use a bpf_prog_active
counter to bail out in case a program is already running on
that CPU out of a different context. XDP and cls_bpf programs
by themselves don't have this issue as they run in the same
context only. Therefore, split both perf_sample_data so they
cannot be accessed from each other.
Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data")
Reported-by: Alexei Starovoitov <ast@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Tested-by: Song Liu <songliubraving@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions