Message-ID: <48172D30.8030104@trash.net>
Date:	Tue, 29 Apr 2008 16:14:08 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Silviu Vlasceanu <silviuvlasceanu@...oo.com>
CC:	netdev@...r.kernel.org
Subject: Re: [BUG,NETFILTER] nfqnl_mangle() not requesting enough space for
 bigger reinjected packet.

Silviu Vlasceanu wrote:
> Arnaud Ebalard <arno <at> natisbad.org> writes:
>
>   
>> Hi,
>>
>> 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
>> ------------[ cut here ]------------
>> invalid opcode: 0000 [#1] PREEMPT 
>> Process sendd (pid: 3657, ti=f6014000 task=f77c31d0 task.ti=f6014000)
>> Stack: c071e638 c04fddb0 000002b8 00000278 f7592c00 f7592c00 f7592eb8 f7592e80 
>>        f763c000 f6bc5200 f7592c40 f6015c34 c04cdbfc f6bc5200 00000278 f6015c60 
>>        c04fddb0 00000020 f72a10c0 f751b420 00000001 0000000a 000002b8 c065582c 
>> Call Trace:
>>  [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
>>  [<c04cdbfc>] ? skb_put+0x3c/0x40
>>  [<c04fddb0>] ? nfqnl_recv_verdict+0x1c0/0x2e0
>>  [<c04fd115>] ? nfnetlink_rcv_msg+0xf5/0x160
>>  [<c04fd03e>] ? nfnetlink_rcv_msg+0x1e/0x160
>>  [<c04fd020>] ? nfnetlink_rcv_msg+0x0/0x160
>>  [<c04f8ed7>] ? netlink_rcv_skb+0x77/0xa0
>>  [<c04fcefc>] ? nfnetlink_rcv+0x1c/0x30
>>  [<c04f8c73>] ? netlink_unicast+0x243/0x2b0
>>  [<c04cfaba>] ? memcpy_fromiovec+0x4a/0x70
>>  [<c04f9406>] ? netlink_sendmsg+0x1c6/0x270
>>  [<c04c8244>] ? sock_sendmsg+0xc4/0xf0
>>  [<c011970d>] ? set_next_entity+0x1d/0x50
>>  [<c0133a80>] ? autoremove_wake_function+0x0/0x40
>>  [<c0118f9e>] ? __wake_up_common+0x3e/0x70
>>  [<c0342fbf>] ? n_tty_receive_buf+0x34f/0x1280
>>  [<c011d308>] ? __wake_up+0x68/0x70
>>  [<c02cea47>] ? copy_from_user+0x37/0x70
>>  [<c04cfd7c>] ? verify_iovec+0x2c/0x90
>>  [<c04c837a>] ? sys_sendmsg+0x10a/0x230
>>  [<c011967a>] ? __dequeue_entity+0x2a/0xa0
>>  [<c011970d>] ? set_next_entity+0x1d/0x50
>>  [<c0345397>] ? pty_write+0x47/0x60
>>  [<c033d59b>] ? tty_default_put_char+0x1b/0x20
>>  [<c011d2e9>] ? __wake_up+0x49/0x70
>>  [<c033df99>] ? tty_ldisc_deref+0x39/0x90
>>  [<c033ff20>] ? tty_write+0x1a0/0x1b0
>>  [<c04c93af>] ? sys_socketcall+0x7f/0x260
>>  [<c0102ff9>] ? sysenter_past_esp+0x6a/0x91
>>  [<c05f0000>] ? snd_intel8x0m_probe+0x270/0x6e0
>>  =======================
>> Code: 00 00 89 5c 24 14 8b 98 9c 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89
>>     
> 4c 24 04 c7 04 24 38 e6 71 c0 89 44 24 08 e8 c4 46 c5
>   
>> ff <0f> 0b eb fe 55 89 e5 56 89 d6 53 89 c3 83 ec 0c 8b 40 50 39 d0 
>> EIP: [<c04ccdfc>] skb_over_panic+0x5c/0x60 SS:ESP 0068:f6015bf8
>>
>> 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.
>>
>> Cheers,
>>
>> a+
>>
>>
>> Attachment (bad_argument_to_skb_copy_expand_in_nfqnl_mangle.patch):
>>     
> text/x-diff, 2002 bytes
>
> Hello,
>
> I have tried sendd on 2.6.24-1 and there still seems to be a problem with it:
>
> ip6_tables: (C) 2000-2006 Netfilter Core Team
> Netfilter messages via NETLINK v0.30.
> skb_over_panic: text:e01fcb93 len:432 put:368 head:de406c00 data:de406c00
> tail:0xde406db0 end:0xde406d20 dev:eth0
> ------------[ cut here ]------------
> kernel BUG at net/core/skbuff.c:95!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: nfnetlink_queue nfnetlink xt_NFQUEUE ip6table_filter
> ip6_tables x_tables ppdev lp ac battery ipv6 fuse dm_snapshot dm_mirror dm_mod
> loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
> snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq
> parport_pc parport snd_timer snd_seq_device serio_raw snd soundcore psmouse
> snd_page_alloc pcspkr iTCO_wdt rtc i2c_i801 i2c_core shpchp pci_hotplug button
> intel_agp agpgart evdev ext3 jbd mbcache ide_cd cdrom ide_disk generic usbhid
> hid piix ide_core floppy ata_generic e1000 ehci_hcd uhci_hcd libata scsi_mod
> usbcore thermal processor fan
>
> Pid: 2265, comm: sendd Not tainted (2.6.24-1-686 #1)
> EIP: 0060:[<c0258a2d>] EFLAGS: 00210296 CPU: 0
> EIP is at skb_over_panic+0x59/0x5d
> EAX: 00000075 EBX: de406c00 ECX: 00200082 EDX: 00200000
> ESI: ddb43000 EDI: dd832280 EBP: ded71b80 ESP: ded6fc28
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process sendd (pid: 2265, ti=ded6e000 task=ded05250 task.ti=ded6e000)
> Stack: c032814b e01fcb93 000001b0 00000170 de406c00 de406c00 de406db0 de406d20
>        ddb43000 000001b0 00000170 e01fcb98 00000020 ddffdc20 dda4d180 00000001
>        e01fcf8c e01fcf80 0000000c ded6fce0 e02f820c ded6fc90 e01fcfc0 ffffffff
> Call Trace:
>  [<e01fcb93>] nfqnl_recv_verdict+0x181/0x20e [nfnetlink_queue]
>  [<e01fcb98>] nfqnl_recv_verdict+0x186/0x20e [nfnetlink_queue]
>  [<e02f820c>] nfnetlink_rcv_msg+0x114/0x154 [nfnetlink]
>  [<e02f80f8>] nfnetlink_rcv_msg+0x0/0x154 [nfnetlink]
>  [<c0272f0d>] netlink_rcv_skb+0x2d/0x7e
>  [<e02f8019>] nfnetlink_rcv+0x19/0x24 [nfnetlink]
>  [<c0272cf4>] netlink_unicast+0x199/0x1f4
>  [<c02734ec>] netlink_sendmsg+0x27c/0x288
>  [<c0225db7>] __add_entropy_words+0x58/0x176
>  [<c02549fb>] sock_sendmsg+0xc9/0xe4
>  [<c01353f9>] autoremove_wake_function+0x0/0x35
>  [<c0254ba8>] sys_sendmsg+0x192/0x1f7
>  [<c016615f>] __do_fault+0x32b/0x36c
>  [<c013abdc>] clocksource_get_next+0x39/0x3f
>  [<c0139c51>] update_wall_time+0x541/0x6a5
>  [<c01680e5>] handle_mm_fault+0x2cf/0x685
>  [<c0115944>] lapic_next_event+0xc/0x10
>  [<c013c08d>] clockevents_program_event+0xe0/0xee
>  [<c012c6a2>] lock_timer_base+0x19/0x35
>  [<c012c7b6>] __mod_timer+0x9a/0xa4
>  [<c0255e01>] sys_socketcall+0x240/0x261
>  [<c0129294>] irq_exit+0x53/0x6b
>  [<c0115e6c>] smp_apic_timer_interrupt+0x71/0x7d
>  [<c0103e5e>] sysenter_past_esp+0x6b/0xa1
>  =======================
> Code: 00 00 89 5c 24 14 8b 98 a0 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 50 89 4c
> 24 04 c7 04 24 4b 81 32 c0 89 44 24 08 e8 75 c7 ec ff <0f> 0b eb fe 56 89 d6 53
> 89 c3 83 ec 0c 8b 40 50 39 c2 76 04 0f
> EIP: [<c0258a2d>] skb_over_panic+0x59/0x5d SS:ESP 0068:ded6fc28
> ---[ end trace 012d67e9de71128b ]---
> [drm] Initialized drm 1.1.0 20060810
> sid:~# uname -r
> 2.6.24-1-686
>
> I have't patched yet my 2.6.25 kernel with the patch you provided, so I have
> tried sendd on 2.6.24-1, as you said there are no problems with it (sendd
> installed via the .deb packages you uploaded on rfc. ...
>
> Do you have idea of what could be causing this?

Could send me the code your using for testing? I want to make sure
we've really fixed it this time ...

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists