summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/bpf/test_sockmap.c
diff options
context:
space:
mode:
authorPu Lehui <pulehui@huawei.com>2024-06-22 03:04:36 +0000
committerDaniel Borkmann <daniel@iogearbox.net>2024-07-01 17:10:46 +0200
commit9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9 (patch)
treef366bcd2adfc8d82678325158ee437a5889fcea7 /tools/testing/selftests/bpf/test_sockmap.c
parentd1a426171d76b2cdf3dea5d52f6266090e4aa254 (diff)
downloadlinux-9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9.tar.gz
linux-9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9.tar.bz2
linux-9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9.zip
riscv, bpf: Fix out-of-bounds issue when preparing trampoline image
We get the size of the trampoline image during the dry run phase and allocate memory based on that size. The allocated image will then be populated with instructions during the real patch phase. But after commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im` argument is inconsistent in the dry run and real patch phase. This may cause emit_imm in RV64 to generate a different number of instructions when generating the 'im' address, potentially causing out-of-bounds issues. Let's emit the maximum number of instructions for the "im" address during dry run to fix this problem. Fixes: 26ef208c209a ("bpf: Use arch_bpf_trampoline_size") Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20240622030437.3973492-3-pulehui@huaweicloud.com
Diffstat (limited to 'tools/testing/selftests/bpf/test_sockmap.c')
0 files changed, 0 insertions, 0 deletions