| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1442332400.131189.21.camel@infradead.org>
Date: Tue, 15 Sep 2015 16:53:20 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: netdev <netdev@...r.kernel.org>
Subject: IPv6 routing/fragmentation panic
I can repeatably crash my router with 'ping6 -s 2000' to an external
machine:
[ 61.741618] skbuff: skb_under_panic: text:c1277f1e len:1294 put:14 head:dec98000 data:dec97ffc tail:0xdec9850a end:0xdec98f40 dev:br-lan
[ 61.754128] ------------[ cut here ]------------
[ 61.758754] Kernel BUG at c1201b1f [verbose debug info unavailable]
[ 61.764005] invalid opcode: 0000 [#1]
[ 61.764005] Modules linked in: sch_teql 8139cp mii iptable_nat pppoe nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT solos_pci pppox ppp_async nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ledtrig_heartbeat ledtrig_gpio ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables pppoatm ppp_generic slhc br2684 atm geode_aes cbc arc4 aes_i586
[ 61.764005] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #2
[ 61.764005] task: c138d540 ti: c1386000 task.ti: c1386000
[ 61.764005] EIP: 0060:[<c1201b1f>] EFLAGS: 00210286 CPU: 0
[ 61.764005] EIP is at skb_panic+0x3b/0x3d
[ 61.764005] EAX: 0000007c EBX: deca3000 ECX: c13a0910 EDX: c139f3c4
[ 61.764005] ESI: dee85d8c EDI: dec9800a EBP: defe3b40 ESP: dec0bd50
[ 61.764005] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 61.764005] CR0: 8005003b CR2: b7704474 CR3: 1ef0d000 CR4: 00000090
[ 61.764005] Stack:
[ 61.764005] c135e48c c12e1580 c1277f1e 0000050e 0000000e dec98000 dec97ffc dec9850a
[ 61.764005] dec98f40 deca3000 dee85d00 c120337b c12e1580 c1277f1e 00000000 0000000e
[ 61.764005] dee85d7c ff671e02 deca3000 c109afd3 00200282 00001d91 00000028 dec98012
[ 61.764005] Call Trace:
[ 61.764005] [<c1277f1e>] ? ip6_finish_output2+0x196/0x4da
[ 61.764005] [<c120337b>] ? skb_push+0x2c/0x2c
[ 61.764005] [<c1277f1e>] ? ip6_finish_output2+0x196/0x4da
[ 61.764005] [<c109afd3>] ? __kmalloc_track_caller+0x5a/0xd9
[ 61.764005] [<c10840d6>] ? kmemdup+0x15/0x4a
[ 61.764005] [<c1277d88>] ? ip6_forward_finish+0xa/0xa
[ 61.764005] [<c127aad4>] ? ip6_fragment+0x924/0xb49
[ 61.764005] [<c1277d88>] ? ip6_forward_finish+0xa/0xa
[ 61.764005] [<c122fda6>] ? nf_hook_slow+0x50/0x92
[ 61.764005] [<c127ae23>] ? ip6_output+0x85/0xeb
[ 61.764005] [<c127acf9>] ? ip6_fragment+0xb49/0xb49
[ 61.764005] [<c1279fa0>] ? ip6_forward+0x4a9/0x6b9
[ 61.764005] [<c1277d7e>] ? ac6_proc_exit+0xd/0xd
[ 61.764005] [<c127b46c>] ? ip6_make_skb+0x15f/0x15f
[ 61.764005] [<c127b4e6>] ? ip6_rcv_finish+0x7a/0x7e
[ 61.764005] [<e02bb0c4>] ? ipv6_defrag+0xc3/0xc5 [nf_defrag_ipv6]
[ 61.764005] [<c127b46c>] ? ip6_make_skb+0x15f/0x15f
[ 61.764005] [<c122fd4d>] ? nf_iterate+0x5b/0x64
[ 61.764005] [<c122fda6>] ? nf_hook_slow+0x50/0x92
[ 61.764005] [<c127babb>] ? ipv6_rcv+0x305/0x470
[ 61.764005] [<c127b46c>] ? ip6_make_skb+0x15f/0x15f
[ 61.764005] [<c120c04d>] ? __netif_receive_skb_core+0x643/0x836
[ 61.764005] [<c100632a>] ? nommu_map_page+0x2d/0x4d
[ 61.764005] [<e036a153>] ? solos_bh+0x681/0x751 [solos_pci]
[ 61.764005] [<c120dc51>] ? process_backlog+0x45/0x96
[ 61.764005] [<c120d6a9>] ? net_rx_action+0x15b/0x238
[ 61.764005] [<c102dcfc>] ? __do_softirq+0xb4/0x18a
[ 61.764005] [<c102dc48>] ? __hrtimer_tasklet_trampoline+0x12/0x12
[ 61.764005] [<c1002feb>] ? do_softirq_own_stack+0x1b/0x20
[ 61.764005] <IRQ>
[ 61.764005] [<c1002e24>] ? do_IRQ+0x38/0x9a
[ 61.764005] [<c12bbd89>] ? common_interrupt+0x29/0x30
[ 61.764005] [<c1007d2e>] ? default_idle+0x2/0x3
[ 61.764005] [<c10080fc>] ? arch_cpu_idle+0x6/0x7
[ 61.764005] [<c1044cf6>] ? cpu_startup_entry+0xed/0x189
[ 61.764005] [<c13bc9ac>] ? start_kernel+0x2e5/0x2e8
[ 61.764005] Code: ff b0 9c 00 00 00 ff b0 98 00 00 00 ff b0 a4 00 00 00 ff b0 a0 00 00 00 52 ff 70 54 51 ff 74 24 28 68 8c e4 35 c1 e8 9c 73 0b 00 <0f> 0b 89 c1 83 79 58 00 8b 80 98 00 00 00 75 17 53 8d 1c 10 01
[ 61.764005] EIP: [<c1201b1f>] skb_panic+0x3b/0x3d SS:ESP 0068:dec0bd50
[ 62.120408] ---[ end trace 45d5375a04f3aef4 ]---
[ 62.125034] Kernel panic - not syncing: Fatal exception in interrupt
[ 62.130381] Kernel Offset: disabled
[ 62.130381] Rebooting in 3 seconds..<FF>
I can 'fix' it thus (which demonstrates that the issue was with incoming
packets arriving over PPPoATM and being routed out the internal Ethernet):
--- drivers/atm/solos-pci.c~ 2015-08-31 23:19:23.000000000 +0100
+++ drivers/atm/solos-pci.c 2015-09-15 15:10:42.534125968 +0100
@@ -869,8 +869,9 @@ static void solos_bh(unsigned long card_
/* Allocate RX skbs for any ports which need them */
if (card->using_dma && card->atmdev[port] &&
!card->rx_skb[port]) {
- struct sk_buff *skb = alloc_skb(RX_DMA_SIZE, GFP_ATOMIC);
+ struct sk_buff *skb = alloc_skb(RX_DMA_SIZE + 16, GFP_ATOMIC);
if (skb) {
+ skb_reserve(skb, 16);
SKB_CB(skb)->dma_addr =
pci_map_single(card->dev, skb->data,
RX_DMA_SIZE, PCI_DMA_FROMDEVICE);
Now, I probably should have done this a long time ago, because that
lack of headroom probably meant that the machine was always having to
reallocate buffers just to fit the Ethernet header on the front of them
when routing incoming packets. So I might be happy enough with
submitting a variant of the above patch and calling it a performance
improvement.
But should the kernel *panic* without it? If there are requirements on
the headroom I must leave on received packets, where are they
documented? Or is this a bug in the IPv6 fragmentation code, to make
such assumptions?
I'm not entirely sure how to interpret the above stack trace. Is the
incoming IPv6 packet being reassembled for netfilter's benefit, then re
-fragmented for transmission?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)
Powered by blists - more mailing lists