Francesco Ruggeri <fruggeri@xxxxxxxxxx> wrote: > > Maybe a different bug that passes a *wrong* size argument somehow > > that would under-allocate tmp? mid underflow? right >= xt[af].cur? > > If I am interpreting this correctly, at the time of the panic (at 7c) > "right" is 0x2580249 (in ECX), originally coming from xt[af].cur via: > > 59: 48 6b ff 70 imul $0x70,%rdi,%rdi > 5d: 48 03 3d 00 00 00 00 add 0x0(%rip),%rdi > ... > 67: 8b 4f 6c mov 0x6c(%rdi),%ecx > ... > 6e: ff c9 dec %ecx > > and later possibly modified in the loop. > xt[af].cur is set to 0 in xt_compat_init_offsets(). Is it also guaranteed > to be 0 if xt_compat_init_offsets() is skipped? Its set to 0 in xt_compat_flush_offsets(), maybe there is a code path that doesn't call it before returning to userspace. I suspect we should always call xt_compat_init_offsets() and make it handle a 0 size arg, just to rule out a missing call to xt_compat_init_offsets() as a problem source.
