On Mon, Nov 30, 2015 at 7:29 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Mon, Nov 30, 2015 at 01:02:55PM +0100, Daniel Borkmann wrote: >> During own review but also reported by Dmitry's syzkaller [1] it has been >> noticed that we trigger a heap out-of-bounds access on eBPF array maps >> when updating elements. This happens with each map whose map->value_size >> (specified during map creation time) is not multiple of 8 bytes. > ... >> In case of array_map_lookup_elem(), the verifier prevents eBPF programs >> from accessing beyond map->value_size through check_map_access(). Also >> from syscall side map_lookup_elem() only copies map->value_size back to >> user, so nothing could leak. >> >> [1] http://github.com/google/syzkaller >> >> Fixes: 28fbcfa08d8e ("bpf: add array type of eBPF maps") >> Reported-by: Dmitry Vyukov <dvyu...@google.com> >> Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> > > Dmitry, thanks a lot for applying syzkaller to bpf. The issues > got cought much sooner than they would have been discovered otherwise. > Looks like the fuzzing has limited dependency chains described > in sys/sys.txt. Can they be improved into doing something like: > single call to map_create followed by many calls to update to > stress oom ? I did it manually so far without kasan.
Hi Alexei, Please elaborate. sys.txt describes signatures of syscalls. Based on that syzkaller generates programs that can contain a map_create call followed by multiple map update calls. Though, it won't generate millions of update calls on a single map, because it directly conflicts with the idea of coverage guided fuzzing. For OOMs I guess you want to try kmalloc fault injection. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
