Re: bpf: undefined shift in __bpf_prog_run

2015-12-09 Thread Daniel Borkmann
On 12/04/2015 08:10 PM, Alexei Starovoitov wrote: On Fri, Dec 04, 2015 at 08:03:47PM +0100, Dmitry Vyukov wrote: is it with some random seccomp program? If normal libseccomp generates such programs than it needs to be fixed. Yes, it is with completely random seccomp program. Such shifts have

RE: bpf: undefined shift in __bpf_prog_run

2015-12-07 Thread David Laight
From: Dmitry Vyukov > Sent: 04 December 2015 19:49 ... > 3.4.3 > undefined behavior > 1 behavior, upon use of a nonportable or erroneous program construct > or of erroneous data, for which this International Standard imposes no > requirements > 2 NOTE Possible undefined behavior ranges from ignorin

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread David Miller
From: Alexei Starovoitov Date: Fri, 4 Dec 2015 12:35:23 -0800 > On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote: >> >> For example, a compiler can assume that result of left shift is larger >> or equal to first operand, which in turn can allow it to elide some >> bounds check in co

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Hannes Frederic Sowa
Hello, On Fri, Dec 4, 2015, at 20:48, Dmitry Vyukov wrote: > On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote: > > From: Alexei Starovoitov > > Date: Fri, 4 Dec 2015 11:10:15 -0800 > > > >> just don't generate random bpf programs with such shifts. > > > > Agreed, it is exactly the same as if t

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Alexei Starovoitov
On Fri, Dec 04, 2015 at 12:44:09PM -0800, Kostya Serebryany wrote: > On Fri, Dec 4, 2015 at 12:35 PM, Alexei Starovoitov < > alexei.starovoi...@gmail.com> wrote: > > > On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote: > > > > > > For example, a compiler can assume that result of left

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Alexei Starovoitov
On Fri, Dec 04, 2015 at 08:48:57PM +0100, Dmitry Vyukov wrote: > > For example, a compiler can assume that result of left shift is larger > or equal to first operand, which in turn can allow it to elide some > bounds check in code, which in turn can lead to an exploit. I am not > saying that this

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Dmitry Vyukov
On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote: > From: Alexei Starovoitov > Date: Fri, 4 Dec 2015 11:10:15 -0800 > >> just don't generate random bpf programs with such shifts. > > Agreed, it is exactly the same as if the compiler emitted real cpu > shift instructions with undefined behavior.

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread David Miller
From: Alexei Starovoitov Date: Fri, 4 Dec 2015 11:10:15 -0800 > just don't generate random bpf programs with such shifts. Agreed, it is exactly the same as if the compiler emitted real cpu shift instructions with undefined behavior. The creator of the BPF code in question is what should be fixe

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Alexei Starovoitov
On Fri, Dec 04, 2015 at 08:03:47PM +0100, Dmitry Vyukov wrote: > > is it with some random seccomp program? > > If normal libseccomp generates such programs than it needs to be fixed. > > Yes, it is with completely random seccomp program. > > >> Such shifts have undefined behavior according to C s

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Dmitry Vyukov
On Fri, Dec 4, 2015 at 7:43 PM, Alexei Starovoitov wrote: > On Fri, Dec 04, 2015 at 12:17:08PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> UBSAN reports the following undefined behavior: >> >> UBSAN: Undefined behaviour in kernel/bpf/core.c:336:2 >> shift exponent 2835 is to large for 32-bit type

Re: bpf: undefined shift in __bpf_prog_run

2015-12-04 Thread Alexei Starovoitov
On Fri, Dec 04, 2015 at 12:17:08PM +0100, Dmitry Vyukov wrote: > Hello, > > UBSAN reports the following undefined behavior: > > UBSAN: Undefined behaviour in kernel/bpf/core.c:336:2 > shift exponent 2835 is to large for 32-bit type 'unsigned int' > CPU: 1 PID: 14227 Comm: syzkaller_execu Not tain