On 2022/04/21 16:17, Tetsuo Handa wrote:
> Also, I tried to find what bpf_skb_load_helper_8_no_cache() is doing
> but I couldn't find the implementation of ____bpf_skb_load_helper_8().
> Where is ____bpf_skb_load_helper_8() defined?
>
> ----------------------------------------
> BPF_CALL_2(bpf_skb_load_helper_8_no_cache, const struct sk_buff *, skb,
> int, offset)
> {
> return ____bpf_skb_load_helper_8(skb, skb->data, skb->len - skb->data_len,
> offset);
> }
> ----------------------------------------
>
Ah, OK. Since BPF_CALL_x macro defines
static __always_inline \
u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__))
, BPF_CALL_4(bpf_skb_load_helper_8) will define
static __always_inline u64 ____bpf_skb_load_helper_8()
for to be called from BPF_CALL_2(bpf_skb_load_helper_8_no_cache).
> I feel that amount of output above is too short for "char program[2053]".
> How can TCP/IPv6 socket be created from this quite limited operations?
Since bpf_skb_load_helper_8() nothing but reads a byte, I don't think that
bpf(BPF_PROG_LOAD) / setsockopt(SOL_SOCKET, SO_ATTACH_BPF) can affect this
use-after-free bug, unless "char program[2053]" is doing something other
than reading a byte.
