mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-11 20:56:41 +07:00
bpf: let verifier to calculate and record max_pkt_offset
In check_packet_access, update max_pkt_offset after the offset has passed __check_packet_access. It should be safe to use u32 for max_pkt_offset as explained in code comment. Also, when there is tail call, the max_pkt_offset of the called program is unknown, so conservatively set max_pkt_offset to MAX_PACKET_OFF for such case. Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
This commit is contained in:
parent
bce6a14996
commit
e647815a4d
@ -293,6 +293,7 @@ struct bpf_prog_aux {
|
||||
atomic_t refcnt;
|
||||
u32 used_map_cnt;
|
||||
u32 max_ctx_offset;
|
||||
u32 max_pkt_offset;
|
||||
u32 stack_depth;
|
||||
u32 id;
|
||||
u32 func_cnt;
|
||||
|
@ -1455,6 +1455,17 @@ static int check_packet_access(struct bpf_verifier_env *env, u32 regno, int off,
|
||||
verbose(env, "R%d offset is outside of the packet\n", regno);
|
||||
return err;
|
||||
}
|
||||
|
||||
/* __check_packet_access has made sure "off + size - 1" is within u16.
|
||||
* reg->umax_value can't be bigger than MAX_PACKET_OFF which is 0xffff,
|
||||
* otherwise find_good_pkt_pointers would have refused to set range info
|
||||
* that __check_packet_access would have rejected this pkt access.
|
||||
* Therefore, "off + reg->umax_value + size - 1" won't overflow u32.
|
||||
*/
|
||||
env->prog->aux->max_pkt_offset =
|
||||
max_t(u32, env->prog->aux->max_pkt_offset,
|
||||
off + reg->umax_value + size - 1);
|
||||
|
||||
return err;
|
||||
}
|
||||
|
||||
@ -6138,6 +6149,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
|
||||
*/
|
||||
prog->cb_access = 1;
|
||||
env->prog->aux->stack_depth = MAX_BPF_STACK;
|
||||
env->prog->aux->max_pkt_offset = MAX_PACKET_OFF;
|
||||
|
||||
/* mark bpf_tail_call as different opcode to avoid
|
||||
* conditional branch in the interpeter for every normal
|
||||
|
Loading…
Reference in New Issue
Block a user