ACK: [Precise][CVE-2015-4700] x86: bpf_jit: fix compilation of large bpf programs

[Luis Henriques]

On Thu, Jul 02, 2015 at 11:28:01AM -0700, Kamal Mostafa wrote:
> From: Alexei Starovoitov <ast at plumgrid.com>
> 
> commit 3f7352bf21f8fd7ba3e2fcef9488756f188e12be upstream.
> 
> BugLink: http://bugs.launchpad.net/bugs/1469320
> 
> x86 has variable length encoding. x86 JIT compiler is trying
> to pick the shortest encoding for given bpf instruction.
> While doing so the jump targets are changing, so JIT is doing
> multiple passes over the program. Typical program needs 3 passes.
> Some very short programs converge with 2 passes. Large programs
> may need 4 or 5. But specially crafted bpf programs may hit the
> pass limit and if the program converges on the last iteration
> the JIT compiler will be producing an image full of 'int 3' insns.
> Fix this corner case by doing final iteration over bpf program.
> 
> Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64")
> Reported-by: Daniel Borkmann <daniel at iogearbox.net>
> Signed-off-by: Alexei Starovoitov <ast at plumgrid.com>
> Tested-by: Daniel Borkmann <daniel at iogearbox.net>
> Acked-by: Daniel Borkmann <daniel at iogearbox.net>
> Signed-off-by: David S. Miller <davem at davemloft.net>
> CVE-2015-4700
> [ kamal: backport to 3.8 (Ubuntu Precise): context ]
                       ^^
I guess you mean 3.2 here.

Other than that:

Acked-by: Luis Henriques <luis.henriques at canonical.com>

Cheers,
--
Luís

> Signed-off-by: Kamal Mostafa <kamal at canonical.com>
> ---
>  arch/x86/net/bpf_jit_comp.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 5a5b6e4..11e3100 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -150,7 +150,12 @@ void bpf_jit_compile(struct sk_filter *fp)
>  	}
>  	cleanup_addr = proglen; /* epilogue address */
>  
> -	for (pass = 0; pass < 10; pass++) {
> +	/* JITed image shrinks with every pass and the loop iterates
> +	 * until the image stops shrinking. Very large bpf programs
> +	 * may converge on the last pass. In such case do one more
> +	 * pass to emit the final image
> +	 */
> +	for (pass = 0; pass < 10 || image; pass++) {
>  		u8 seen_or_pass0 = (pass == 0) ? (SEEN_XREG | SEEN_DATAREF | SEEN_MEM) : seen;
>  		/* no prologue/epilogue for trivial filters (RET something) */
>  		proglen = 0;
> -- 
> 1.9.1
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team