Re: [RESEND][NETFILTER][PATCH] nfqnl_mangle() not requesting enough space for bigger reinjected packet.

[Patrick McHardy <kaber@trash.net>]

Arnaud Ebalard wrote:
> Hi,
>
> This is a resend, first post was to netdev only and slipped through.
>
> While reinjecting *bigger* modified versions of IPv6 packets using
> libnetfilter_queue, things work fine on a 2.6.24 kernel (2.6.22 too)
> but I get the following on recents kernels (2.6.25, trace below is
> against today's net-2.6 git tree):
>
> skb_over_panic: text:c04fddb0 len:696 put:632 head:f7592c00 data:f7592c00 tail:0xf7592eb8 end:0xf7592e80 dev:eth0
> [...]
> Looking at the code, I ended up in nfq_mangle() function (called by
> nfqnl_recv_verdict()) which performs a call to skb_copy_expand() due to
> the increased size of data passed to the function. AFAICT, it should ask
> for 'diff' instead of 'diff - skb_tailroom(e->skb)'. Because the
> resulting sk_buff has not enough space to support the skb_put(skb, diff)
> call a few lines later, this results in the call to skb_over_panic().
>
> The patch below asks for allocation of a copy with enough space for
> mangled packet and the same amount of headroom as old sk_buff. While
> looking at how the regression appeared (e2b58a67), I noticed the same
> pattern in ipq_mangle_ipv6() and ipq_mangle_ipv4(). The patch corrects
> those locations too.
>
> Tested with bigger reinjected IPv6 packets (nfqnl_mangle() path), things
> are ok (2.6.25 and today's net-2.6 git tree).
>
> Don't hesitate if I missed something.
>   

Good catch, thanks. That code seems to be very resistent against
attempts to fix it :)

Patch applied, and I'll also send it to -stable once it hits
upstream.