summaryrefslogtreecommitdiffstats
path: root/arch/x86/net
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2023-12-18 09:36:01 -0800
committerDaniel Borkmann <daniel@iogearbox.net>2023-12-18 23:54:21 +0100
commit8e432e6197cef6250dfd6fdffd41c06613c874ca (patch)
tree441e472f39005b2d9a16b69dba9b6b40d726f322 /arch/x86/net
parent6079ae6376181b49c9e4d65ef9fe954cca4974bd (diff)
downloadlinux-8e432e6197cef6250dfd6fdffd41c06613c874ca.tar.gz
linux-8e432e6197cef6250dfd6fdffd41c06613c874ca.tar.bz2
linux-8e432e6197cef6250dfd6fdffd41c06613c874ca.zip
bpf: Ensure precise is reset to false in __mark_reg_const_zero()
It is safe to always start with imprecise SCALAR_VALUE register. Previously __mark_reg_const_zero() relied on caller to reset precise mark, but it's very error prone and we already missed it in a few places. So instead make __mark_reg_const_zero() reset precision always, as it's a safe default for SCALAR_VALUE. Explanation is basically the same as for why we are resetting (or rather not setting) precision in current state. If necessary, precision propagation will set it to precise correctly. As such, also remove a big comment about forward precision propagation in mark_reg_stack_read() and avoid unnecessarily setting precision to true after reading from STACK_ZERO stack. Again, precision propagation will correctly handle this, if that SCALAR_VALUE register will ever be needed to be precise. Reported-by: Maxim Mikityanskiy <maxtram95@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Maxim Mikityanskiy <maxtram95@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231218173601.53047-1-andrii@kernel.org
Diffstat (limited to 'arch/x86/net')
0 files changed, 0 insertions, 0 deletions