On Thu, May 17, 2018 at 01:44:11AM +0200, Daniel Borkmann wrote: > Recently during testing, I ran into the following panic: > > Therefore it becomes necessary to detect and reject any such occasions > in a generic way for native eBPF and cBPF to eBPF migrations. For > the latter we can simply check bounds in the bpf_convert_filter()'s > BPF_EMIT_JMP helper macro and bail out once we surpass limits. The > bpf_patch_insn_single() for native eBPF (and cBPF to eBPF in case > of subsequent hardening) is a bit more complex in that we need to > detect such truncations before hitting the bpf_prog_realloc(). Thus > the latter is split into an extra pass to probe problematic offsets > on the original program in order to fail early. With that in place > and carefully tested I no longer hit the panic and the rewrites are > rejected properly. The above example panic I've seen on bpf-next, > though the issue itself is generic in that a guard against this issue > in bpf seems more appropriate in this case. > > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net>
Nice catch! Applied.
