lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 10 Oct 2014 20:16:50 -0700 From: Alexei Starovoitov <ast@...mgrid.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: "David S. Miller" <davem@...emloft.net>, "Darrick J. Wong" <darrick.wong@...cle.com>, Eric Dumazet <edumazet@...gle.com>, Daniel Borkmann <dborkman@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>, Network Development <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH net] x86: bpf_jit: fix two bugs in eBPF JIT compiler On Fri, Oct 10, 2014 at 8:12 PM, Eric Dumazet <eric.dumazet@...il.com> wrote: > On Fri, 2014-10-10 at 19:44 -0700, Alexei Starovoitov wrote: > >> 2. >> while staring at the code realized that 64-byte buffer may not be enough >> when 1st insn is large, so increase it to 128 to avoid buffer overflow >> (theoretical maximum size of prologue+div is 109) and add runtime check. >> > > >> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c >> index d56cd1f..8266896 100644 >> --- a/arch/x86/net/bpf_jit_comp.c >> +++ b/arch/x86/net/bpf_jit_comp.c >> @@ -187,7 +187,8 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image, >> { >> struct bpf_insn *insn = bpf_prog->insnsi; >> int insn_cnt = bpf_prog->len; >> - u8 temp[64]; >> + bool seen_ld_abs = ctx->seen_ld_abs | (oldproglen == 0); >> + u8 temp[128]; > > Hmmm. I would use some guard like : > > #define BPF_MAX_INSN_SIZE 128 > #define BPF_INSN_SAFETY 64 > > u8 temp[MAX_INSN_SIZE + BPF_INSN_SAFETY]; > > >> + if (ilen >= sizeof(temp)) { > > if (ilen > BPF_MAX_INSN_SIZE) { > ... > >> + pr_err("bpf_jit_compile fatal insn size error\n"); >> + return -EFAULT; >> + } >> + > > Otherwise, we might have corrupted stack and panic anyway. well, it only reduces the chances of stack corruption.. but yeah, let's reduce them. will respin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists