* Slab Corruption with ipv6 and tcp6fuzz @ 2008-04-24 14:27 Eric Sesterhenn 2008-04-24 19:48 ` Ilpo Järvinen 2008-04-24 21:13 ` Evgeniy Polyakov 0 siblings, 2 replies; 11+ messages in thread From: Eric Sesterhenn @ 2008-04-24 14:27 UTC (permalink / raw) To: netdev hi, i found some local ivp6 network fuzzing tools from the bsd folks today and wanted to add them to my testmachine. When trying one of them (running with user privs) it gave me slab corruption errors. Running http://clem1.be/lf6/tcp6fuzz.c 1 to 5 times always results in errors, strangely using the same seed twice in a row doesnt trigger the warnings again. If there is any more info i can provide please let me know. A sample of the warnings follows: [ 57.315914] process `tcp6fuzz' is using obsolete setsockopt SO_BSDCOMPAT [ 57.810370] sock_set_timeout: `tcp6fuzz' (pid 3721) tries to set negative timeout [ 215.102729] ============================================================================= [ 215.102786] BUG skbuff_head_cache: Invalid object pointer 0xccd2b520 [ 215.102810] ----------------------------------------------------------------------------- [ 215.102816] [ 215.102840] INFO: Slab 0xc119c560 used=10 fp=0x00000000 flags=0x40000083 [ 215.102868] Pid: 0, comm: swapper Not tainted 2.6.25-03562-g3dc5063 #23 [ 215.102880] [<c0177b57>] slab_err+0x47/0x50 [ 215.102978] [<c0177bc7>] ? slab_pad_check+0x67/0xe0 [ 215.102994] [<c0177c92>] ? check_slab+0x52/0x80 [ 215.103010] [<c0179405>] __slab_free+0x1d5/0x2d0 [ 215.103024] [<c0179eb0>] kmem_cache_free+0x80/0xe0 [ 215.103039] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.103063] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.103078] [<c05d91dc>] __kfree_skb+0x3c/0x90 [ 215.103090] [<c05d9249>] kfree_skb+0x19/0x30 [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 [ 215.103128] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.103161] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.103177] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.103191] [<c012b075>] ? local_bh_enable_ip+0x85/0xf0 [ 215.103220] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.103245] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.103260] [<c0146721>] ? trace_hardirqs_on+0x81/0x150 [ 215.103275] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.103289] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.103317] [<c014424d>] ? put_lock_stats+0xd/0x30 [ 215.103333] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.103349] [<c0706615>] ? _spin_lock_nested+0x65/0x80 [ 215.103377] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.103391] [<c0674f57>] tcp_v6_rcv+0x627/0x710 [ 215.103404] [<c06809c0>] ? ip6t_hook+0x0/0x30 [ 215.103418] [<c05f3c89>] ? nf_iterate+0x59/0x80 [ 215.103448] [<c0653ff2>] ip6_input_finish+0xc2/0x2a0 [ 215.103465] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.103479] [<c06541ef>] ip6_input+0x1f/0x60 [ 215.103491] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.103505] [<c0654464>] ipv6_rcv+0x194/0x2e0 [ 215.103518] [<c0654290>] ? ip6_rcv_finish+0x0/0x40 [ 215.103532] [<c06542d0>] ? ipv6_rcv+0x0/0x2e0 [ 215.103545] [<c05de7f0>] netif_receive_skb+0x280/0x2f0 [ 215.103560] [<c05e1336>] process_backlog+0x76/0xd0 [ 215.103576] [<c05e0c90>] net_rx_action+0x120/0x1a0 [ 215.103589] [<c012ac92>] __do_softirq+0x62/0xc0 [ 215.103602] [<c010676a>] do_softirq+0x8a/0xd0 [ 215.103618] [<c0155f80>] ? handle_level_irq+0x0/0xe0 [ 215.103634] [<c012abc6>] irq_exit+0x86/0x90 [ 215.103647] [<c010684a>] do_IRQ+0x9a/0x100 [ 215.103659] [<c0706e49>] ? _spin_unlock_irqrestore+0x39/0x70 [ 215.103677] [<c01047f2>] common_interrupt+0x2e/0x34 [ 215.103691] [<c0140000>] ? sysfs_override_clocksource+0x70/0x100 [ 215.103706] [<c04b6d42>] ? acpi_idle_enter_simple+0x18a/0x1fc [ 215.103739] [<c058decd>] cpuidle_idle_call+0x5d/0xb0 [ 215.103760] [<c058de70>] ? cpuidle_idle_call+0x0/0xb0 [ 215.103775] [<c0102838>] cpu_idle+0x38/0xa0 [ 215.103787] [<c06f94cc>] rest_init+0x5c/0x60 [ 215.103811] ======================= [ 215.103819] FIX skbuff_head_cache: Object at 0xccd2b520 not freed [ 215.108749] ============================================================================= [ 215.108796] BUG skbuff_head_cache: Invalid object pointer 0xcb13a820 [ 215.108820] ----------------------------------------------------------------------------- [ 215.108826] [ 215.108851] INFO: Slab 0xc1164740 used=5 fp=0xcb13a600 flags=0x40000083 [ 215.108879] Pid: 3172, comm: dd Not tainted 2.6.25-03562-g3dc5063 #23 [ 215.108896] [<c0177b57>] slab_err+0x47/0x50 [ 215.108935] [<c0177bc7>] ? slab_pad_check+0x67/0xe0 [ 215.108951] [<c0177c92>] ? check_slab+0x52/0x80 [ 215.108966] [<c0179405>] __slab_free+0x1d5/0x2d0 [ 215.108981] [<c0179eb0>] kmem_cache_free+0x80/0xe0 [ 215.108995] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.109021] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.109035] [<c05d91dc>] __kfree_skb+0x3c/0x90 [ 215.109048] [<c05d9249>] kfree_skb+0x19/0x30 [ 215.109060] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 [ 215.109086] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.109120] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.109136] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.109151] [<c012b075>] ? local_bh_enable_ip+0x85/0xf0 [ 215.109181] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.109209] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.109224] [<c0146721>] ? trace_hardirqs_on+0x81/0x150 [ 215.109239] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.109253] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.109281] [<c014424d>] ? put_lock_stats+0xd/0x30 [ 215.109296] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.109312] [<c0706615>] ? _spin_lock_nested+0x65/0x80 [ 215.109337] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.109352] [<c0674f57>] tcp_v6_rcv+0x627/0x710 [ 215.109365] [<c06809c0>] ? ip6t_hook+0x0/0x30 [ 215.109379] [<c05f3c89>] ? nf_iterate+0x59/0x80 [ 215.109412] [<c0653ff2>] ip6_input_finish+0xc2/0x2a0 [ 215.109428] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.109443] [<c06541ef>] ip6_input+0x1f/0x60 [ 215.109455] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.109469] [<c0654464>] ipv6_rcv+0x194/0x2e0 [ 215.109481] [<c0654290>] ? ip6_rcv_finish+0x0/0x40 [ 215.109495] [<c06542d0>] ? ipv6_rcv+0x0/0x2e0 [ 215.109508] [<c05de7f0>] netif_receive_skb+0x280/0x2f0 [ 215.109524] [<c05e1336>] process_backlog+0x76/0xd0 [ 215.109540] [<c05e0c90>] net_rx_action+0x120/0x1a0 [ 215.109554] [<c012ac92>] __do_softirq+0x62/0xc0 [ 215.109567] [<c010676a>] do_softirq+0x8a/0xd0 [ 215.109583] [<c0155f80>] ? handle_level_irq+0x0/0xe0 [ 215.109599] [<c012abc6>] irq_exit+0x86/0x90 [ 215.109612] [<c010684a>] do_IRQ+0x9a/0x100 [ 215.109625] [<c01047f2>] common_interrupt+0x2e/0x34 [ 215.109639] [<c0147cff>] ? lock_acquire+0x8f/0xa0 [ 215.109654] [<c01959e0>] ? mnt_want_write+0x20/0x90 [ 215.109677] [<c0706669>] _spin_lock+0x39/0x70 [ 215.109690] [<c01959e0>] ? mnt_want_write+0x20/0x90 [ 215.109704] [<c01959e0>] mnt_want_write+0x20/0x90 [ 215.109717] [<c0191a79>] file_update_time+0x39/0xd0 [ 215.109744] [<c018413a>] pipe_write+0x21a/0x450 [ 215.109772] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.109788] [<c017d55c>] do_sync_write+0xcc/0x110 [ 215.109802] [<c0138a80>] ? autoremove_wake_function+0x0/0x50 [ 215.109827] [<c01b1c9e>] ? dnotify_parent+0x6e/0x80 [ 215.109850] [<c0706d47>] ? _spin_unlock+0x27/0x50 [ 215.109867] [<c017dd99>] vfs_write+0x99/0x130 [ 215.109879] [<c017d490>] ? do_sync_write+0x0/0x110 [ 215.109893] [<c017e38d>] sys_write+0x3d/0x70 [ 215.109906] [<c0103d75>] sysenter_past_esp+0x6a/0xb1 [ 215.109920] ======================= [ 215.109928] FIX skbuff_head_cache: Object at 0xcb13a820 not freed [ 215.116324] ============================================================================= [ 215.116372] BUG skbuff_head_cache: Invalid object pointer 0xccbf10a0 [ 215.116396] ----------------------------------------------------------------------------- [ 215.116401] [ 215.116426] INFO: Slab 0xc1199e20 used=10 fp=0x00000000 flags=0x40000083 [ 215.116455] Pid: 3172, comm: dd Not tainted 2.6.25-03562-g3dc5063 #23 [ 215.116467] [<c0177b57>] slab_err+0x47/0x50 [ 215.116506] [<c0177bc7>] ? slab_pad_check+0x67/0xe0 [ 215.116522] [<c0177c92>] ? check_slab+0x52/0x80 [ 215.116537] [<c0179405>] __slab_free+0x1d5/0x2d0 [ 215.116553] [<c0179eb0>] kmem_cache_free+0x80/0xe0 [ 215.116567] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.116592] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.116606] [<c05d91dc>] __kfree_skb+0x3c/0x90 [ 215.116619] [<c05d9249>] kfree_skb+0x19/0x30 [ 215.116631] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 [ 215.116657] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.116693] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.116709] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.116724] [<c012b075>] ? local_bh_enable_ip+0x85/0xf0 [ 215.116753] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.116781] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.116796] [<c0146721>] ? trace_hardirqs_on+0x81/0x150 [ 215.116811] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.116826] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.116855] [<c014424d>] ? put_lock_stats+0xd/0x30 [ 215.116870] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.116886] [<c0706615>] ? _spin_lock_nested+0x65/0x80 [ 215.116913] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.116928] [<c0674f57>] tcp_v6_rcv+0x627/0x710 [ 215.116941] [<c06809c0>] ? ip6t_hook+0x0/0x30 [ 215.116955] [<c05f3c89>] ? nf_iterate+0x59/0x80 [ 215.116988] [<c0653ff2>] ip6_input_finish+0xc2/0x2a0 [ 215.117006] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.117021] [<c06541ef>] ip6_input+0x1f/0x60 [ 215.117033] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.117047] [<c0654464>] ipv6_rcv+0x194/0x2e0 [ 215.117059] [<c0654290>] ? ip6_rcv_finish+0x0/0x40 [ 215.117073] [<c06542d0>] ? ipv6_rcv+0x0/0x2e0 [ 215.117087] [<c05de7f0>] netif_receive_skb+0x280/0x2f0 [ 215.117102] [<c05e1336>] process_backlog+0x76/0xd0 [ 215.117118] [<c05e0c90>] net_rx_action+0x120/0x1a0 [ 215.117131] [<c012ac92>] __do_softirq+0x62/0xc0 [ 215.117145] [<c010676a>] do_softirq+0x8a/0xd0 [ 215.117161] [<c0155f80>] ? handle_level_irq+0x0/0xe0 [ 215.117178] [<c012abc6>] irq_exit+0x86/0x90 [ 215.117191] [<c010684a>] do_IRQ+0x9a/0x100 [ 215.117203] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.117218] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.117234] [<c01047f2>] common_interrupt+0x2e/0x34 [ 215.117247] [<c070007b>] ? tulip_init_one+0x5eb/0xda0 [ 215.117262] [<c0192e3a>] ? __mnt_is_readonly+0xa/0x20 [ 215.117281] [<c01959e7>] ? mnt_want_write+0x27/0x90 [ 215.117299] [<c0191a79>] file_update_time+0x39/0xd0 [ 215.117322] [<c018413a>] pipe_write+0x21a/0x450 [ 215.117348] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.117364] [<c017d55c>] do_sync_write+0xcc/0x110 [ 215.117378] [<c0138a80>] ? autoremove_wake_function+0x0/0x50 [ 215.117401] [<c01b1c9e>] ? dnotify_parent+0x6e/0x80 [ 215.117423] [<c0706d47>] ? _spin_unlock+0x27/0x50 [ 215.117439] [<c017dd99>] vfs_write+0x99/0x130 [ 215.117451] [<c017d490>] ? do_sync_write+0x0/0x110 [ 215.117465] [<c017e38d>] sys_write+0x3d/0x70 [ 215.117478] [<c0103d75>] sysenter_past_esp+0x6a/0xb1 [ 215.117492] ======================= [ 215.117499] FIX skbuff_head_cache: Object at 0xccbf10a0 not freed [ 215.125990] ============================================================================= [ 215.126042] BUG skbuff_head_cache: Invalid object pointer 0xccbe1820 [ 215.126066] ----------------------------------------------------------------------------- [ 215.126071] [ 215.126095] INFO: Slab 0xc1199c20 used=5 fp=0xccbe1600 flags=0x40000083 [ 215.126123] Pid: 3172, comm: dd Not tainted 2.6.25-03562-g3dc5063 #23 [ 215.126135] [<c0177b57>] slab_err+0x47/0x50 [ 215.126172] [<c0177bc7>] ? slab_pad_check+0x67/0xe0 [ 215.126189] [<c0177c92>] ? check_slab+0x52/0x80 [ 215.126204] [<c0179405>] __slab_free+0x1d5/0x2d0 [ 215.126219] [<c0179eb0>] kmem_cache_free+0x80/0xe0 [ 215.126233] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.126258] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 [ 215.126273] [<c05d91dc>] __kfree_skb+0x3c/0x90 [ 215.126285] [<c05d9249>] kfree_skb+0x19/0x30 [ 215.126298] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 [ 215.126324] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.126359] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.126375] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.126389] [<c012b075>] ? local_bh_enable_ip+0x85/0xf0 [ 215.126420] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.126446] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.126461] [<c0146721>] ? trace_hardirqs_on+0x81/0x150 [ 215.126476] [<c0680718>] ? ip6t_do_table+0x318/0x590 [ 215.126490] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.126519] [<c014424d>] ? put_lock_stats+0xd/0x30 [ 215.126534] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.126550] [<c0706615>] ? _spin_lock_nested+0x65/0x80 [ 215.126580] [<c0674e97>] ? tcp_v6_rcv+0x567/0x710 [ 215.126594] [<c0674f57>] tcp_v6_rcv+0x627/0x710 [ 215.126608] [<c06809c0>] ? ip6t_hook+0x0/0x30 [ 215.126622] [<c05f3c89>] ? nf_iterate+0x59/0x80 [ 215.126654] [<c0653ff2>] ip6_input_finish+0xc2/0x2a0 [ 215.126672] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.126687] [<c06541ef>] ip6_input+0x1f/0x60 [ 215.126699] [<c0653f30>] ? ip6_input_finish+0x0/0x2a0 [ 215.126713] [<c0654464>] ipv6_rcv+0x194/0x2e0 [ 215.126725] [<c0654290>] ? ip6_rcv_finish+0x0/0x40 [ 215.126739] [<c06542d0>] ? ipv6_rcv+0x0/0x2e0 [ 215.126752] [<c05de7f0>] netif_receive_skb+0x280/0x2f0 [ 215.126767] [<c05e1336>] process_backlog+0x76/0xd0 [ 215.126783] [<c05e0c90>] net_rx_action+0x120/0x1a0 [ 215.126796] [<c012ac92>] __do_softirq+0x62/0xc0 [ 215.126810] [<c010676a>] do_softirq+0x8a/0xd0 [ 215.126826] [<c0155f80>] ? handle_level_irq+0x0/0xe0 [ 215.126842] [<c012abc6>] irq_exit+0x86/0x90 [ 215.126855] [<c010684a>] do_IRQ+0x9a/0x100 [ 215.126867] [<c0109637>] ? native_sched_clock+0x67/0xb0 [ 215.126883] [<c01047f2>] common_interrupt+0x2e/0x34 [ 215.126897] [<c0140000>] ? sysfs_override_clocksource+0x70/0x100 [ 215.126912] [<c0706e67>] ? _spin_unlock_irqrestore+0x57/0x70 [ 215.126929] [<c011e5c6>] __wake_up_sync+0x46/0x60 [ 215.126942] [<c0184119>] pipe_write+0x1f9/0x450 [ 215.126968] [<c0146fe5>] ? __lock_acquire+0x395/0x1020 [ 215.126983] [<c017d55c>] do_sync_write+0xcc/0x110 [ 215.126997] [<c0138a80>] ? autoremove_wake_function+0x0/0x50 [ 215.127021] [<c01b1c9e>] ? dnotify_parent+0x6e/0x80 [ 215.127044] [<c0706d47>] ? _spin_unlock+0x27/0x50 [ 215.127059] [<c017dd99>] vfs_write+0x99/0x130 [ 215.127071] [<c017d490>] ? do_sync_write+0x0/0x110 [ 215.127085] [<c017e38d>] sys_write+0x3d/0x70 [ 215.127098] [<c0103d75>] sysenter_past_esp+0x6a/0xb1 [ 215.127112] ======================= [ 215.127119] FIX skbuff_head_cache: Object at 0xccbe1820 not freed Greetings, Eric ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-24 14:27 Slab Corruption with ipv6 and tcp6fuzz Eric Sesterhenn @ 2008-04-24 19:48 ` Ilpo Järvinen 2008-04-24 21:13 ` Evgeniy Polyakov 1 sibling, 0 replies; 11+ messages in thread From: Ilpo Järvinen @ 2008-04-24 19:48 UTC (permalink / raw) To: Eric Sesterhenn; +Cc: Netdev On Thu, 24 Apr 2008, Eric Sesterhenn wrote: > Running http://clem1.be/lf6/tcp6fuzz.c 1 to 5 times ...I couldn't fetch it, refuses connection...? -- i. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-24 14:27 Slab Corruption with ipv6 and tcp6fuzz Eric Sesterhenn 2008-04-24 19:48 ` Ilpo Järvinen @ 2008-04-24 21:13 ` Evgeniy Polyakov 2008-04-25 12:52 ` Eric Sesterhenn 1 sibling, 1 reply; 11+ messages in thread From: Evgeniy Polyakov @ 2008-04-24 21:13 UTC (permalink / raw) To: Eric Sesterhenn; +Cc: netdev Hi. On Thu, Apr 24, 2008 at 04:27:27PM +0200, Eric Sesterhenn (snakebyte@gmx.de) wrote: > i found some local ivp6 network fuzzing tools from the bsd folks > today and wanted to add them to my testmachine. When > trying one of them (running with user privs) it gave me slab corruption errors. > Running http://clem1.be/lf6/tcp6fuzz.c 1 to 5 times > always results in errors, strangely using the same seed twice > in a row doesnt trigger the warnings again. > > If there is any more info i can provide please let me know. $ wget http://clem1.be/lf6/tcp6fuzz.c --01:09:26-- http://clem1.be/lf6/tcp6fuzz.c => `tcp6fuzz.c' Resolving clem1.be... 88.169.180.107 Connecting to clem1.be|88.169.180.107|:80... failed: Connection refused. Please post your source here (google can not find it either), if it is that easily reproducible, you can be sure, bug will be fixed in a few moments. > [ 57.810370] sock_set_timeout: `tcp6fuzz' (pid 3721) tries to set negative timeout > [ 215.102729] ============================================================================= > [ 215.102786] BUG skbuff_head_cache: Invalid object pointer 0xccd2b520 > [ 215.102810] ----------------------------------------------------------------------------- > [ 215.102816] > [ 215.102840] INFO: Slab 0xc119c560 used=10 fp=0x00000000 flags=0x40000083 > [ 215.102868] Pid: 0, comm: swapper Not tainted 2.6.25-03562-g3dc5063 #23 > [ 215.102880] [<c0177b57>] slab_err+0x47/0x50 > [ 215.102978] [<c0177bc7>] ? slab_pad_check+0x67/0xe0 > [ 215.102994] [<c0177c92>] ? check_slab+0x52/0x80 > [ 215.103010] [<c0179405>] __slab_free+0x1d5/0x2d0 > [ 215.103024] [<c0179eb0>] kmem_cache_free+0x80/0xe0 > [ 215.103039] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 > [ 215.103063] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 > [ 215.103078] [<c05d91dc>] __kfree_skb+0x3c/0x90 > [ 215.103090] [<c05d9249>] kfree_skb+0x19/0x30 > [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 So far can you run kernel with debug turned on and provide output of gdb ./vmlinux l *(tcp_v6_do_rcv+0x33b) -- Evgeniy Polyakov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-24 21:13 ` Evgeniy Polyakov @ 2008-04-25 12:52 ` Eric Sesterhenn 2008-04-25 13:09 ` Evgeniy Polyakov 0 siblings, 1 reply; 11+ messages in thread From: Eric Sesterhenn @ 2008-04-25 12:52 UTC (permalink / raw) To: Evgeniy Polyakov; +Cc: netdev * Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote: > Hi. > > On Thu, Apr 24, 2008 at 04:27:27PM +0200, Eric Sesterhenn (snakebyte@gmx.de) wrote: > > i found some local ivp6 network fuzzing tools from the bsd folks > > today and wanted to add them to my testmachine. When > > trying one of them (running with user privs) it gave me slab corruption errors. > > Running http://clem1.be/lf6/tcp6fuzz.c 1 to 5 times > > always results in errors, strangely using the same seed twice > > in a row doesnt trigger the warnings again. > > > > If there is any more info i can provide please let me know. > > $ wget http://clem1.be/lf6/tcp6fuzz.c > --01:09:26-- http://clem1.be/lf6/tcp6fuzz.c > => `tcp6fuzz.c' > Resolving clem1.be... 88.169.180.107 > Connecting to clem1.be|88.169.180.107|:80... failed: Connection refused. > > Please post your source here (google can not find it either), if it is > that easily reproducible, you can be sure, bug will be fixed in a few > moments. > > > [ 57.810370] sock_set_timeout: `tcp6fuzz' (pid 3721) tries to set negative timeout > > [ 215.102729] ============================================================================= > > [ 215.102786] BUG skbuff_head_cache: Invalid object pointer 0xccd2b520 > > [ 215.102810] ----------------------------------------------------------------------------- > > [ 215.102816] > > [ 215.102840] INFO: Slab 0xc119c560 used=10 fp=0x00000000 flags=0x40000083 > > [ 215.102868] Pid: 0, comm: swapper Not tainted 2.6.25-03562-g3dc5063 #23 > > [ 215.102880] [<c0177b57>] slab_err+0x47/0x50 > > [ 215.102978] [<c0177bc7>] ? slab_pad_check+0x67/0xe0 > > [ 215.102994] [<c0177c92>] ? check_slab+0x52/0x80 > > [ 215.103010] [<c0179405>] __slab_free+0x1d5/0x2d0 > > [ 215.103024] [<c0179eb0>] kmem_cache_free+0x80/0xe0 > > [ 215.103039] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 > > [ 215.103063] [<c05d91dc>] ? __kfree_skb+0x3c/0x90 > > [ 215.103078] [<c05d91dc>] __kfree_skb+0x3c/0x90 > > [ 215.103090] [<c05d9249>] kfree_skb+0x19/0x30 > > [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 > > So far can you run kernel with debug turned on and provide output of > gdb ./vmlinux > l *(tcp_v6_do_rcv+0x33b) l *(tcp_v6_do_rcv+0x33b) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) l *(tcp_v6_do_rcv+0x33b) 0xc0671e3b is in tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670). 1665 reset: 1666 tcp_v6_send_reset(sk, skb); 1667 discard: 1668 if (opt_skb) 1669 __kfree_skb(opt_skb); 1670 kfree_skb(skb); 1671 return 0; 1672 csum_err: 1673 TCP_INC_STATS_BH(TCP_MIB_INERRS); 1674 goto discard; Here is the programm itself... Greetings, Eric /* * TCP/IPV6 socket fuzzer. * * Copyright (C) 2006, Clément Lecigne */ #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <netdb.h> #include <stdlib.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/ioctl.h> #include <signal.h> #include <sys/uio.h> void usage(char *); void randsoopt(int); void fs(char *, size_t); void fc(uint32_t, uint32_t, uint32_t, size_t, char *); unsigned int randaddr(void); /* * boucle until we hit a valid socket option */ void randsoopt(int sock) { unsigned int optval; int optlen, optname, level, ret, on = rand() % 2; do { switch (rand() % 4) { case 0: level = IPPROTO_IPV6; break; case 1: level = SOL_SOCKET; break; case 2: level = IPPROTO_TCP; break; case 3: level = rand() & 0xFF; break; } if (rand() % 8) { optlen = rand() & 0xffff; optval = randaddr(); } else { /* * In some cases, kernel excepts that * optlen == sizeof (int) and that's * the first bound checking. */ optlen = sizeof (int); optval = (unsigned int)&on; } if (rand() % 8) optname = rand() % 80; else optname = rand(); #if 0 /* * anti well know mbufs exhaustion. (FreeBSD) */ if (optname == 25 || optname == IPV6_IPSEC_POLICY || optname == IPV6_FW_ADD || optname == IPV6_FW_FLUSH || optname == IPV6_FW_DEL || optname == IPV6_FW_ZERO) continue; #endif ret = setsockopt(sock, level, optname, (void *)optval, optlen); }while(ret == -1); } /* * server fuzzage. */ void fs(char *port, size_t ms) { int so, ac, one = 1; struct addrinfo *res, hints; struct sockaddr_in6 from; socklen_t fromlen; char *buf; struct msghdr m; struct cmsghdr *c = NULL; struct iovec io; buf = malloc(ms); if (buf == NULL) { perror(" - malloc"); return; } fromlen = sizeof from; memset(&hints, 0, sizeof hints); hints.ai_family = AF_INET6; hints.ai_socktype = SOCK_STREAM; hints.ai_protocol = IPPROTO_TCP; getaddrinfo("::1", port, &hints, &res); m.msg_name = res->ai_addr; m.msg_namelen = res->ai_addrlen; m.msg_iov = &io; so = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if (so == -1){ perror("sock"); exit(EXIT_FAILURE); } randsoopt(so); if (bind(so, res->ai_addr, res->ai_addrlen) < 0){ perror("bind"); exit(EXIT_FAILURE); } if (listen(so, 0) < 0){ perror("listen"); exit(EXIT_FAILURE); } while(1) { randsoopt(so); ac = accept(so, (struct sockaddr *)&from, &fromlen); if (ac == -1){ perror("accept"); continue; /* warn but continue */ } randsoopt(ac); /* make ac non-blockant */ ioctl(ac, FIONBIO, &one); /* different receiving ways */ switch(rand() % 3) { case 0: /* basic read */ read(ac, buf, rand() % ms); break; case 1: /* recvfrom */ recvfrom(ac, buf, rand() % ms, 0, (struct sockaddr *)&from, &fromlen); break; case 2: /* recvmsg */ m.msg_iovlen = (rand() % 2) ? rand() : 1; m.msg_controllen = (rand() % 2) ? CMSG_LEN(rand() % ms) : 0; if (m.msg_controllen) { c = (struct cmsghdr *)malloc(m.msg_controllen); m.msg_control = c; c->cmsg_level = (rand() % 2) ? IPPROTO_IPV6 : rand(); c->cmsg_type = (rand() % 2) ? rand() % 255 : rand(); c->cmsg_len = (rand() % 2) ? m.msg_controllen : rand(); } else { m.msg_control = (rand() % 5) ? NULL : (void*)randaddr(); } m.msg_flags = rand(); io.iov_len = (rand() % 2) ? rand() : rand() % ms; recvmsg(ac, &m, (rand() % 2) ? 0 : rand()); break; } close(ac); } free(buf); freeaddrinfo(res); } /* * client fuzzage. */ void fc(uint32_t count, uint32_t occ, uint32_t opts, size_t ms, char *port) { int so, j, cc, one = 1; uint32_t try; u_int32_t i, a; struct addrinfo *res, hints; char *buf; struct msghdr m; struct cmsghdr *c = NULL; struct iovec io; /* XXX: wait server */ usleep(500); buf = malloc(ms); if (buf == NULL) { perror(" - malloc"); return; } signal(SIGPIPE, SIG_IGN); memset(&hints, 0, sizeof(hints)); hints.ai_family = AF_INET6; hints.ai_socktype = SOCK_STREAM; hints.ai_protocol = IPPROTO_TCP; getaddrinfo("::1", port, &hints, &res); m.msg_name = res->ai_addr; m.msg_namelen = res->ai_addrlen; m.msg_iov = &io; for (i = 0; i < occ; i++) { printf("%d\n", i); try = 0; do{ so = socket(res->ai_family, res->ai_socktype, res->ai_protocol); try++; }while(so == -1 && count != try); /* make socket non-blockant */ ioctl(so, FIONBIO, &one); try = 0; do{ cc = connect(so, res->ai_addr, res->ai_addrlen); try++; }while(cc == -1 && count != try); randsoopt(so); for (a = 0; a < opts; a++) { try = 0; do { switch(rand() % 3) { case 0: cc = write(so, buf, rand() % ms); break; case 1: cc = sendto(so, buf, rand() % ms, MSG_DONTWAIT, (struct sockaddr *)&res->ai_addr, res->ai_addrlen); break; case 2: m.msg_iovlen = (rand() % 2) ? rand() : 1; m.msg_controllen = (rand() % 2) ? CMSG_LEN(rand() % ms) : 0; m.msg_flags = MSG_DONTWAIT; if (m.msg_controllen) { c = (struct cmsghdr *)malloc(m.msg_controllen); m.msg_control = c; c->cmsg_level = (rand() % 2) ? IPPROTO_IPV6 : rand(); c->cmsg_type = (rand() % 2) ? rand() % 255 : rand(); c->cmsg_len = (rand() % 2) ? m.msg_controllen : rand(); } else { m.msg_control = (rand() % 5) ? NULL : (void*)randaddr(); m.msg_controllen = (rand() % 2) ? rand() : 0; } io.iov_len = (rand() % 2) ? rand() : rand() % ms; cc = sendmsg (so, &m, MSG_DONTWAIT); } if (c != NULL) { free(c); c = NULL; } try++; }while(cc == -1 && count != try); } close(so); } free(buf); freeaddrinfo(res); return; } /* * return a random address */ unsigned int randaddr(void) { int stack; char *p = malloc(1); unsigned int heap = (unsigned int)p; free(p); switch (rand() % 4) { case 0: return (heap + (rand() & 0xFFF)); case 1: return ((unsigned int)&stack + (rand() & 0xFFF)); case 2: return (0xc0000000 + (rand() & 0xFFFF)); case 3: return (rand()); } return (0); } /* * usage */ void usage(char *prog) { printf("usage: %s [-r seed] [-c sendto-timeout] [-m maxsize]\n" " [-o maxsetsockopt] [-n occ] [-p tcp-port]\n", prog); exit(1); } int main(int ac, char **av) { int32_t occ, count, opts; u_int32_t seed; size_t maxsize; char c; pid_t pid; char *port = "5000"; /* default values */ seed = getpid(); count = 50; occ = 100; maxsize = 4096; opts = 10; while ((c = getopt(ac, av, "r:n:c:p:m:o:")) != EOF) { switch (c) { case 'r': seed = atoi(optarg); break; case 'n': occ = atoi(optarg); break; case 'c': count = atoi(optarg); break; case 'p': port = optarg; break; case 'm': maxsize = atoi(optarg); break; case 'o': opts = atoi(optarg); break; default: usage(av[0]); break; } } printf(" + using seed : %d\n", seed); srand(seed); puts(" + forking."); pid = fork(); switch (pid) { case -1: perror(" - fork"); exit(EXIT_FAILURE); case 0: /* client fuzzer */ fs(port, maxsize); break; default: /* server */ fc(count, occ, opts, maxsize, port); break; } /* client finished, kill the serv */ kill(pid, SIGKILL); puts(" + fuzzing finished, your kernel is alive."); exit(EXIT_SUCCESS); } ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-25 12:52 ` Eric Sesterhenn @ 2008-04-25 13:09 ` Evgeniy Polyakov 2008-04-26 16:05 ` Evgeniy Polyakov 0 siblings, 1 reply; 11+ messages in thread From: Evgeniy Polyakov @ 2008-04-25 13:09 UTC (permalink / raw) To: Eric Sesterhenn; +Cc: netdev, davem, ilpo.jarvinen On Fri, Apr 25, 2008 at 02:52:30PM +0200, Eric Sesterhenn (snakebyte@gmx.de) wrote: > > > [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 > > > > So far can you run kernel with debug turned on and provide output of > > gdb ./vmlinux > > l *(tcp_v6_do_rcv+0x33b) > > l *(tcp_v6_do_rcv+0x33b) > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > (gdb) l *(tcp_v6_do_rcv+0x33b) > 0xc0671e3b is in tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670). > 1665 reset: > 1666 tcp_v6_send_reset(sk, skb); > 1667 discard: > 1668 if (opt_skb) > 1669 __kfree_skb(opt_skb); > 1670 kfree_skb(skb); > 1671 return 0; > 1672 csum_err: > 1673 TCP_INC_STATS_BH(TCP_MIB_INERRS); > 1674 goto discard; Well, first possible error path: tcp_v6_do_rcv()->tcp_rcv_established(), the latter goes to step5, where eventually skb can be freed via tcp_data_queue() (drop: label), then if check for tcp_defer_accept_check() returns true and thus tcp_rcv_established() returns -1, which forces tcp_v6_do_rcv() to jump to reset: label, which in turn will pass through discard: label and free the same skb again. > Here is the programm itself... I will work on this this weekend, thank you. -- Evgeniy Polyakov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-25 13:09 ` Evgeniy Polyakov @ 2008-04-26 16:05 ` Evgeniy Polyakov 2008-04-27 6:05 ` David Miller 2008-04-27 16:48 ` Patrick McManus 0 siblings, 2 replies; 11+ messages in thread From: Evgeniy Polyakov @ 2008-04-26 16:05 UTC (permalink / raw) To: Eric Sesterhenn; +Cc: netdev, davem, ilpo.jarvinen Hi. On Fri, Apr 25, 2008 at 05:09:46PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote: > On Fri, Apr 25, 2008 at 02:52:30PM +0200, Eric Sesterhenn (snakebyte@gmx.de) wrote: > > > > [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 > > > > > > So far can you run kernel with debug turned on and provide output of > > > gdb ./vmlinux > > > l *(tcp_v6_do_rcv+0x33b) > > > > l *(tcp_v6_do_rcv+0x33b) > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (gdb) l *(tcp_v6_do_rcv+0x33b) > > 0xc0671e3b is in tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670). > > 1665 reset: > > 1666 tcp_v6_send_reset(sk, skb); > > 1667 discard: > > 1668 if (opt_skb) > > 1669 __kfree_skb(opt_skb); > > 1670 kfree_skb(skb); > > 1671 return 0; > > 1672 csum_err: > > 1673 TCP_INC_STATS_BH(TCP_MIB_INERRS); > > 1674 goto discard; > > Well, first possible error path: > > tcp_v6_do_rcv()->tcp_rcv_established(), the latter goes to step5, where > eventually skb can be freed via tcp_data_queue() (drop: label), then if > check for tcp_defer_accept_check() returns true and thus > tcp_rcv_established() returns -1, which forces tcp_v6_do_rcv() to jump > to reset: label, which in turn will pass through discard: label and free > the same skb again. > > > Here is the programm itself... > > I will work on this this weekend, thank you. Ok, I can not reproduce it, so lets try hard way. Can you test attached patch, its idea is described above and I checked multiple times, that it is forbidden to free skb and return non-zero value from tcp_rcv_established(). This behaviour was introduced with TCP defer accept changes in 2.6.25 with ec3c0982a2dd1e671bad8e9d26c28dcba0039d87 commit. Please test. This bug affects both ipv6 and ipv4 code actually. diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index ac9b848..0298f80 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -4925,8 +4925,7 @@ step5: tcp_data_snd_check(sk); tcp_ack_snd_check(sk); - if (tcp_defer_accept_check(sk)) - return -1; + tcp_defer_accept_check(sk); return 0; csum_error: -- Evgeniy Polyakov ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-26 16:05 ` Evgeniy Polyakov @ 2008-04-27 6:05 ` David Miller 2008-04-27 13:25 ` Patrick McManus 2008-04-27 16:48 ` Patrick McManus 1 sibling, 1 reply; 11+ messages in thread From: David Miller @ 2008-04-27 6:05 UTC (permalink / raw) To: johnpol; +Cc: snakebyte, netdev, ilpo.jarvinen, mcmanus, dada1 From: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Date: Sat, 26 Apr 2008 20:05:20 +0400 Patrick, please look at this, your defer-accept changes are causing crashes. See below. Eric, I'm CC:'ing you because you ACK'd some of this stuff :-)) > On Fri, Apr 25, 2008 at 05:09:46PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote: > > On Fri, Apr 25, 2008 at 02:52:30PM +0200, Eric Sesterhenn (snakebyte@gmx.de) wrote: > > > > > [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 > > > > > > > > So far can you run kernel with debug turned on and provide output of > > > > gdb ./vmlinux > > > > l *(tcp_v6_do_rcv+0x33b) > > > > > > l *(tcp_v6_do_rcv+0x33b) > > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > > (gdb) l *(tcp_v6_do_rcv+0x33b) > > > 0xc0671e3b is in tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670). > > > 1665 reset: > > > 1666 tcp_v6_send_reset(sk, skb); > > > 1667 discard: > > > 1668 if (opt_skb) > > > 1669 __kfree_skb(opt_skb); > > > 1670 kfree_skb(skb); > > > 1671 return 0; > > > 1672 csum_err: > > > 1673 TCP_INC_STATS_BH(TCP_MIB_INERRS); > > > 1674 goto discard; > > > > Well, first possible error path: > > > > tcp_v6_do_rcv()->tcp_rcv_established(), the latter goes to step5, where > > eventually skb can be freed via tcp_data_queue() (drop: label), then if > > check for tcp_defer_accept_check() returns true and thus > > tcp_rcv_established() returns -1, which forces tcp_v6_do_rcv() to jump > > to reset: label, which in turn will pass through discard: label and free > > the same skb again. > > > > > Here is the programm itself... > > > > I will work on this this weekend, thank you. > > Ok, I can not reproduce it, so lets try hard way. > Can you test attached patch, its idea is described above and I checked > multiple times, that it is forbidden to free skb and return non-zero > value from tcp_rcv_established(). This behaviour was introduced with TCP > defer accept changes in 2.6.25 with > ec3c0982a2dd1e671bad8e9d26c28dcba0039d87 commit. > > Please test. This bug affects both ipv6 and ipv4 code actually. > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index ac9b848..0298f80 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -4925,8 +4925,7 @@ step5: > tcp_data_snd_check(sk); > tcp_ack_snd_check(sk); > > - if (tcp_defer_accept_check(sk)) > - return -1; > + tcp_defer_accept_check(sk); > return 0; > > csum_error: > > > -- > Evgeniy Polyakov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-27 6:05 ` David Miller @ 2008-04-27 13:25 ` Patrick McManus 2008-04-27 15:32 ` Eric Sesterhenn 0 siblings, 1 reply; 11+ messages in thread From: Patrick McManus @ 2008-04-27 13:25 UTC (permalink / raw) To: David Miller; +Cc: johnpol, snakebyte, netdev, ilpo.jarvinen, dada1 I'll take a look asap - thanks for the cc:, I've been away. -Patrick On Sat, 2008-04-26 at 23:05 -0700, David Miller wrote: > From: Evgeniy Polyakov <johnpol@2ka.mipt.ru> > Date: Sat, 26 Apr 2008 20:05:20 +0400 > > Patrick, please look at this, your defer-accept changes are causing > crashes. See below. > > Eric, I'm CC:'ing you because you ACK'd some of this stuff :-)) > > > On Fri, Apr 25, 2008 at 05:09:46PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote: > > > On Fri, Apr 25, 2008 at 02:52:30PM +0200, Eric Sesterhenn (snakebyte@gmx.de) wrote: > > > > > > [ 215.103103] [<c0671e3b>] tcp_v6_do_rcv+0x33b/0xcd0 > > > > > > > > > > So far can you run kernel with debug turned on and provide output of > > > > > gdb ./vmlinux > > > > > l *(tcp_v6_do_rcv+0x33b) > > > > > > > > l *(tcp_v6_do_rcv+0x33b) > > > > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > > > (gdb) l *(tcp_v6_do_rcv+0x33b) > > > > 0xc0671e3b is in tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670). > > > > 1665 reset: > > > > 1666 tcp_v6_send_reset(sk, skb); > > > > 1667 discard: > > > > 1668 if (opt_skb) > > > > 1669 __kfree_skb(opt_skb); > > > > 1670 kfree_skb(skb); > > > > 1671 return 0; > > > > 1672 csum_err: > > > > 1673 TCP_INC_STATS_BH(TCP_MIB_INERRS); > > > > 1674 goto discard; > > > > > > Well, first possible error path: > > > > > > tcp_v6_do_rcv()->tcp_rcv_established(), the latter goes to step5, where > > > eventually skb can be freed via tcp_data_queue() (drop: label), then if > > > check for tcp_defer_accept_check() returns true and thus > > > tcp_rcv_established() returns -1, which forces tcp_v6_do_rcv() to jump > > > to reset: label, which in turn will pass through discard: label and free > > > the same skb again. > > > > > > > Here is the programm itself... > > > > > > I will work on this this weekend, thank you. > > > > Ok, I can not reproduce it, so lets try hard way. > > Can you test attached patch, its idea is described above and I checked > > multiple times, that it is forbidden to free skb and return non-zero > > value from tcp_rcv_established(). This behaviour was introduced with TCP > > defer accept changes in 2.6.25 with > > ec3c0982a2dd1e671bad8e9d26c28dcba0039d87 commit. > > > > Please test. This bug affects both ipv6 and ipv4 code actually. > > > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > > index ac9b848..0298f80 100644 > > --- a/net/ipv4/tcp_input.c > > +++ b/net/ipv4/tcp_input.c > > @@ -4925,8 +4925,7 @@ step5: > > tcp_data_snd_check(sk); > > tcp_ack_snd_check(sk); > > > > - if (tcp_defer_accept_check(sk)) > > - return -1; > > + tcp_defer_accept_check(sk); > > return 0; > > > > csum_error: > > > > > > -- > > Evgeniy Polyakov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-27 13:25 ` Patrick McManus @ 2008-04-27 15:32 ` Eric Sesterhenn 0 siblings, 0 replies; 11+ messages in thread From: Eric Sesterhenn @ 2008-04-27 15:32 UTC (permalink / raw) To: Patrick McManus; +Cc: David Miller, johnpol, netdev, ilpo.jarvinen, dada1 * Patrick McManus (mcmanus@ducksong.com) wrote: > I'll take a look asap - thanks for the cc:, I've been away. Evgeniys patch fixes the issue for me and i see no more corruptions. Eric > > > Ok, I can not reproduce it, so lets try hard way. > > > Can you test attached patch, its idea is described above and I checked > > > multiple times, that it is forbidden to free skb and return non-zero > > > value from tcp_rcv_established(). This behaviour was introduced with TCP > > > defer accept changes in 2.6.25 with > > > ec3c0982a2dd1e671bad8e9d26c28dcba0039d87 commit. > > > > > > Please test. This bug affects both ipv6 and ipv4 code actually. > > > > > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > > > index ac9b848..0298f80 100644 > > > --- a/net/ipv4/tcp_input.c > > > +++ b/net/ipv4/tcp_input.c > > > @@ -4925,8 +4925,7 @@ step5: > > > tcp_data_snd_check(sk); > > > tcp_ack_snd_check(sk); > > > > > > - if (tcp_defer_accept_check(sk)) > > > - return -1; > > > + tcp_defer_accept_check(sk); > > > return 0; > > > > > > csum_error: ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-26 16:05 ` Evgeniy Polyakov 2008-04-27 6:05 ` David Miller @ 2008-04-27 16:48 ` Patrick McManus 2008-04-27 22:27 ` David Miller 1 sibling, 1 reply; 11+ messages in thread From: Patrick McManus @ 2008-04-27 16:48 UTC (permalink / raw) To: Evgeniy Polyakov; +Cc: Eric Sesterhenn, netdev, davem, ilpo.jarvinen On Sat, 2008-04-26 at 20:05 +0400, Evgeniy Polyakov wrote: > > tcp_v6_do_rcv()->tcp_rcv_established(), the latter goes to step5, where > > eventually skb can be freed via tcp_data_queue() (drop: label), then if > > check for tcp_defer_accept_check() returns true and thus > > tcp_rcv_established() returns -1, which forces tcp_v6_do_rcv() to jump > > to reset: label, which in turn will pass through discard: label and free > > the same skb again. > > yep. That buggy test was logic from a different strategy long discarded.. the skb is always queued/dropped independently of defer_accept_check() and as such it shouldn't impact the return value of rcv_established. I was able to reproduce by forcing the fuzzer to play with DEFER_ACCEPT 100% of the time, and with the patch tests out fine as do the original defer_accept tests. Sorry for the bug, and thanks Evgeniy for fixing it and Eric for finding it. Acked-By: Patrick McManus <mcmanus@ducksong.com> > > Please test. This bug affects both ipv6 and ipv4 code actually. > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index ac9b848..0298f80 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -4925,8 +4925,7 @@ step5: > tcp_data_snd_check(sk); > tcp_ack_snd_check(sk); > > - if (tcp_defer_accept_check(sk)) > - return -1; > + tcp_defer_accept_check(sk); > return 0; > > csum_error: > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Slab Corruption with ipv6 and tcp6fuzz 2008-04-27 16:48 ` Patrick McManus @ 2008-04-27 22:27 ` David Miller 0 siblings, 0 replies; 11+ messages in thread From: David Miller @ 2008-04-27 22:27 UTC (permalink / raw) To: mcmanus; +Cc: johnpol, snakebyte, netdev, ilpo.jarvinen From: Patrick McManus <mcmanus@ducksong.com> Date: Sun, 27 Apr 2008 12:48:26 -0400 > Sorry for the bug, and thanks Evgeniy for fixing it and Eric for finding > it. > > Acked-By: Patrick McManus <mcmanus@ducksong.com> Patch applied, thanks everyone! ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-04-27 22:27 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-04-24 14:27 Slab Corruption with ipv6 and tcp6fuzz Eric Sesterhenn 2008-04-24 19:48 ` Ilpo Järvinen 2008-04-24 21:13 ` Evgeniy Polyakov 2008-04-25 12:52 ` Eric Sesterhenn 2008-04-25 13:09 ` Evgeniy Polyakov 2008-04-26 16:05 ` Evgeniy Polyakov 2008-04-27 6:05 ` David Miller 2008-04-27 13:25 ` Patrick McManus 2008-04-27 15:32 ` Eric Sesterhenn 2008-04-27 16:48 ` Patrick McManus 2008-04-27 22:27 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).