summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorDaniel Borkmann <daniel@iogearbox.net>2017-12-12 02:25:30 +0100
committerAlexei Starovoitov <ast@kernel.org>2017-12-12 09:51:12 -0800
commit283ca526a9bd75aed7350220d7b1f8027d99c3fd (patch)
treee702c33467d5fc7b2c3b807addc3269774b9f40c /arch
parent30791ac41927ebd3e75486f9504b6d2280463bf0 (diff)
downloadlinux-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