Francesco Ruggeri <fruggeri@xxxxxxxxxx> wrote:
> On Mon, Jan 28, 2019 at 1:50 AM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> >
> > On Mon, Jan 21, 2019 at 09:54:36PM +0100, Florian Westphal wrote:
> > > Unlike ip(6)tables ebtables only counts user-defined chains.
> > >
> > > The effect is that a 32bit ebtables binary on a 64bit kernel can do
> > > 'ebtables -N FOO' only after adding at least one rule, else the request
> > > fails with -EINVAL.
> > >
> > > This is a similar fix as done in
> > > 3f1e53abff84 ("netfilter: ebtables: don't attempt to allocate 0-sized compat array").
> >
> > Applied, thanks Florian.
>
> After running this patch for a few days I got this panic.
> It seems to be because when we skip xt_compat_init_offsets()
> in compat_do_replace(), we also fail to set some values in
> xt[NFPROTO_BRIDGE] that are later needed in
> pr_debug(..., xt_compat_calc_jump(NFPROTO_BRIDGE, ...))
Hmm, can't explain it unfortunately.
xt_compat_calc_jump():
struct compat_delta *tmp = xt[af].compat_tab;
int mid, left = 0, right = xt[af].cur - 1;
while (left <= right) {
..
}
return left ? tmp[left - 1].delta : 0;
So if xt_compat_init_offsets() would not have run, then
left = 0 and right = -1, so loop isn't taken, and it would return 0.
tmp (== NULL) would not be dereferenced in this case.
Maybe a different bug that passes a *wrong* size argument somehow
that would under-allocate tmp? mid underflow? right >= xt[af].cur?
