[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20161207.131804.1728136405665915871.davem@davemloft.net>
Date: Wed, 07 Dec 2016 13:18:04 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: daniel@...earbox.net
Cc: alexei.starovoitov@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bpf: fix loading of BPF_MAXINSNS sized
programs
From: Daniel Borkmann <daniel@...earbox.net>
Date: Wed, 7 Dec 2016 01:15:44 +0100
> General assumption is that single program can hold up to BPF_MAXINSNS,
> that is, 4096 number of instructions. It is the case with cBPF and
> that limit was carried over to eBPF. When recently testing digest, I
> noticed that it's actually not possible to feed 4096 instructions
> via bpf(2).
>
> The check for > BPF_MAXINSNS was added back then to bpf_check() in
> cbd357008604 ("bpf: verifier (add ability to receive verification log)").
> However, 09756af46893 ("bpf: expand BPF syscall with program load/unload")
> added yet another check that comes before that into bpf_prog_load(),
> but this time bails out already in case of >= BPF_MAXINSNS.
>
> Fix it up and perform the check early in bpf_prog_load(), so we can drop
> the second one in bpf_check(). It makes sense, because also a 0 insn
> program is useless and we don't want to waste any resources doing work
> up to bpf_check() point. The existing bpf(2) man page documents E2BIG
> as the official error for such cases, so just stick with it as well.
>
> Fixes: 09756af46893 ("bpf: expand BPF syscall with program load/unload")
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Acked-by: Alexei Starovoitov <ast@...nel.org>
> ---
> ( net-next is just fine imho. )
Applied.
Powered by blists - more mailing lists