grsecurity forums

Posted: **Wed Sep 14, 2016 5:59 am**

Hello,

I noticed an issue on an old 4.5.2 (grsecurity-3.1-4.5.2-201604290633.patch) with an uptime of ~40 days (config).
Unfortunately I don't know what triggered it, so I don't know how to reproduce.
I'll run a 4.7.3 (grsecurity-3.1-4.7.3-201609072139.patch) and update if it reproduces, in the meantime here are the details if anyone wants to take a look.

Log is interesting, 3 detected size overflow (I use pax_size_overflow_report_only) followed by a detected kernel memory leak attempt:

Code: Select all: PAX: size overflow detected in function ipv6_get_l4proto net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:83 PAX: size overflow detected in function __dev_queue_xmit include/linux/skbuff.h PAX: size overflow detected in function br_dev_xmit include/linux/skbuff.h:2147 PAX: kernel memory leak attempt detected from ffff880104d5f2c0 (radix_tree_node) (1294 bytes)

Full log:

Code: Select all: Sep 14 05:00:56 kernel: [3306540.486709] PAX: size overflow detected in function ipv6_get_l4proto net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:83 cicus.107_26 max, count: 1, decl: ipv6_skip_exthdr$ Sep 14 05:00:56 kernel: [3306540.489457] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.2-grsec #1 Sep 14 05:00:56 kernel: [3306540.489458] Hardware name: System manufacturer System Product Name/P8H77-I, BIOS 1001 02/01/2013 Sep 14 05:00:56 kernel: [3306540.489459] ffffffff81e048c7 0000000000000286 0000000000000000 ffff88041fb83ac8 Sep 14 05:00:56 kernel: [3306540.489461] ffffffff813e35ab 0000000000000001 ffffffffa043f478 0000000000000053 Sep 14 05:00:56 kernel: [3306540.489463] ffff88041fb83af8 ffffffff8122b206 00000000ffffffd0 ffff88040c11f500 Sep 14 05:00:56 kernel: [3306540.489465] Call Trace: Sep 14 05:00:56 kernel: [3306540.489466] <IRQ> [<ffffffff813e35ab>] dump_stack+0x4e/0x7b Sep 14 05:00:56 kernel: [3306540.489475] [<ffffffffa043f478>] ? invmap+0x62/0xa75 [nf_conntrack_ipv6] Sep 14 05:00:56 kernel: [3306540.489478] [<ffffffff8122b206>] report_size_overflow+0x6e/0x90 Sep 14 05:00:56 kernel: [3306540.489480] [<ffffffffa043e1d7>] ipv6_get_l4proto+0xaf/0xc0 [nf_conntrack_ipv6] Sep 14 05:00:56 kernel: [3306540.489486] [<ffffffffa041af97>] nf_conntrack_in+0x9f/0x490 [nf_conntrack] Sep 14 05:00:56 kernel: [3306540.489488] [<ffffffffa04378bd>] ? nf_ct_frag6_gather+0x4b5/0x11f0 [nf_defrag_ipv6] Sep 14 05:00:56 kernel: [3306540.489491] [<ffffffffa043e4b8>] ipv6_conntrack_in+0x20/0x40 [nf_conntrack_ipv6] Sep 14 05:00:56 kernel: [3306540.489493] [<ffffffff81756199>] nf_iterate+0x81/0xa0 Sep 14 05:00:56 kernel: [3306540.489495] [<ffffffff81756218>] nf_hook_slow+0x60/0xb0 Sep 14 05:00:56 kernel: [3306540.489498] [<ffffffff817e4ccf>] ipv6_rcv+0x4a7/0x6d0 Sep 14 05:00:56 kernel: [3306540.489500] [<ffffffff81828905>] ? tpacket_rcv+0x5d/0xb00 Sep 14 05:00:56 kernel: [3306540.489502] [<ffffffff811b7947>] ? __alloc_pages_nodemask+0x15f/0xb40 Sep 14 05:00:56 kernel: [3306540.489503] [<ffffffff817e42b8>] ? ip6_make_skb+0x1e0/0x1e0 Sep 14 05:00:56 kernel: [3306540.489506] [<ffffffff81711cc9>] __netif_receive_skb_core+0x381/0xce0 Sep 14 05:00:56 kernel: [3306540.489508] [<ffffffff8181f100>] ? ipv6_gro_receive+0x368/0xb90 Sep 14 05:00:56 kernel: [3306540.489510] [<ffffffff81712641>] __netif_receive_skb+0x19/0x80 Sep 14 05:00:56 kernel: [3306540.489512] [<ffffffff817126c6>] netif_receive_skb_internal+0x1e/0x90 Sep 14 05:00:56 kernel: [3306540.489513] [<ffffffff81713ba1>] napi_gro_receive+0x79/0xd0 Sep 14 05:00:56 kernel: [3306540.489517] [<ffffffffa00dc815>] rtl8169_poll+0x2fd/0x760 [r8169] Sep 14 05:00:56 kernel: [3306540.489519] [<ffffffff81712f99>] net_rx_action+0x341/0x510 Sep 14 05:00:56 kernel: [3306540.489522] [<ffffffff810df5ae>] __do_softirq+0x106/0x210 Sep 14 05:00:56 kernel: [3306540.489524] [<ffffffff810df808>] irq_exit+0x80/0x90 Sep 14 05:00:56 kernel: [3306540.489526] [<ffffffff81058949>] do_IRQ+0x51/0x100 Sep 14 05:00:56 kernel: [3306540.489529] [<ffffffff8184e40b>] common_interrupt+0x8b/0x8b Sep 14 05:00:56 kernel: [3306540.489530] <EOI> [<ffffffff816bb212>] ? cpuidle_enter_state+0x10a/0x1f0 Sep 14 05:00:56 kernel: [3306540.489534] [<ffffffff816bb207>] ? cpuidle_enter_state+0xff/0x1f0 Sep 14 05:00:56 kernel: [3306540.489535] [<ffffffff816bb368>] cpuidle_enter+0x20/0x40 Sep 14 05:00:56 kernel: [3306540.489537] [<ffffffff8111f0d6>] call_cpuidle+0x3e/0x70 Sep 14 05:00:56 kernel: [3306540.489539] [<ffffffff8111f3ed>] cpu_startup_entry+0x175/0x230 Sep 14 05:00:56 kernel: [3306540.489541] [<ffffffff81092149>] start_secondary+0x1d1/0x290 Sep 14 05:00:56 kernel: [3306540.489548] PAX: size overflow detected in function __dev_queue_xmit include/linux/skbuff.h:2147 cicus.2247_338 max, count: 237, decl: mac_header; num: 0; context: sk_bu$ Sep 14 05:00:56 kernel: [3306540.492277] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.2-grsec #1 Sep 14 05:00:56 kernel: [3306540.492278] Hardware name: System manufacturer System Product Name/P8H77-I, BIOS 1001 02/01/2013 Sep 14 05:00:56 kernel: [3306540.492279] ffffffff81e048c7 0000000000000286 0000000000000000 ffff88041fb83970 Sep 14 05:00:56 kernel: [3306540.492280] ffffffff813e35ab 0000000000000001 ffffffff81bd82f8 0000000000000863 Sep 14 05:00:56 kernel: [3306540.492282] ffff88041fb839a0 ffffffff8122b206 ffff88040b2d2020 0000000100000040 Sep 14 05:00:56 kernel: [3306540.492283] Call Trace: Sep 14 05:00:56 kernel: [3306540.492284] <IRQ> [<ffffffff813e35ab>] dump_stack+0x4e/0x7b Sep 14 05:00:56 kernel: [3306540.492288] [<ffffffff8122b206>] report_size_overflow+0x6e/0x90 Sep 14 05:00:56 kernel: [3306540.492289] [<ffffffff8171656d>] __dev_queue_xmit+0x555/0x6c0 Sep 14 05:00:56 kernel: [3306540.492290] [<ffffffff817166ea>] dev_queue_xmit+0x12/0x30 Sep 14 05:00:56 kernel: [3306540.492293] [<ffffffff81721a4d>] neigh_resolve_output+0x135/0x200 Sep 14 05:00:56 kernel: [3306540.492294] [<ffffffff817defec>] ip6_finish_output2+0x194/0x4a0 Sep 14 05:00:56 kernel: [3306540.492295] [<ffffffff817de788>] ? ac6_proc_exit+0x30/0x30 Sep 14 05:00:56 kernel: [3306540.492297] [<ffffffff81756199>] ? nf_iterate+0x81/0xa0 Sep 14 05:00:56 kernel: [3306540.492299] [<ffffffff817e3652>] ip6_finish_output+0xaa/0x120 Sep 14 05:00:56 kernel: [3306540.492300] [<ffffffff817e189e>] ip6_output+0x66/0x110 Sep 14 05:00:56 kernel: [3306540.492301] [<ffffffff817e35a8>] ? ip6_fragment+0x1200/0x1200 Sep 14 05:00:56 kernel: [3306540.492303] [<ffffffff817de8b5>] ip6_forward_finish+0x3d/0x60 Sep 14 05:00:56 kernel: [3306540.492304] [<ffffffff817e1e38>] ip6_forward+0x4f0/0xa60 Sep 14 05:00:56 kernel: [3306540.492306] [<ffffffff817f10be>] ? ip6_route_input_lookup.isra.53+0x46/0x60 Sep 14 05:00:56 kernel: [3306540.492308] [<ffffffff817de878>] ? ndisc_hashfn+0x40/0x40 Sep 14 05:00:56 kernel: [3306540.492309] [<ffffffff817e4308>] ip6_rcv_finish+0x50/0xe0 Sep 14 05:00:56 kernel: [3306540.492310] [<ffffffff817e4b7f>] ipv6_rcv+0x357/0x6d0 Sep 14 05:00:56 kernel: [3306540.492312] [<ffffffff81828905>] ? tpacket_rcv+0x5d/0xb00 Sep 14 05:00:56 kernel: [3306540.492313] [<ffffffff811b7947>] ? __alloc_pages_nodemask+0x15f/0xb40 Sep 14 05:00:56 kernel: [3306540.492314] [<ffffffff817e42b8>] ? ip6_make_skb+0x1e0/0x1e0 Sep 14 05:00:56 kernel: [3306540.492316] [<ffffffff81711cc9>] __netif_receive_skb_core+0x381/0xce0 Sep 14 05:00:56 kernel: [3306540.492318] [<ffffffff8181f100>] ? ipv6_gro_receive+0x368/0xb90 Sep 14 05:00:56 kernel: [3306540.492320] [<ffffffff81712641>] __netif_receive_skb+0x19/0x80 Sep 14 05:00:56 kernel: [3306540.492322] [<ffffffff817126c6>] netif_receive_skb_internal+0x1e/0x90 Sep 14 05:00:56 kernel: [3306540.492323] [<ffffffff81713ba1>] napi_gro_receive+0x79/0xd0 Sep 14 05:00:56 kernel: [3306540.492326] [<ffffffffa00dc815>] rtl8169_poll+0x2fd/0x760 [r8169] Sep 14 05:00:56 kernel: [3306540.492327] [<ffffffff81712f99>] net_rx_action+0x341/0x510 Sep 14 05:00:56 kernel: [3306540.492329] [<ffffffff810df5ae>] __do_softirq+0x106/0x210 Sep 14 05:00:56 kernel: [3306540.492331] [<ffffffff810df808>] irq_exit+0x80/0x90 Sep 14 05:00:56 kernel: [3306540.492333] [<ffffffff81058949>] do_IRQ+0x51/0x100 Sep 14 05:00:56 kernel: [3306540.492334] [<ffffffff8184e40b>] common_interrupt+0x8b/0x8b Sep 14 05:00:56 kernel: [3306540.492335] <EOI> [<ffffffff816bb212>] ? cpuidle_enter_state+0x10a/0x1f0 Sep 14 05:00:56 kernel: [3306540.492338] [<ffffffff816bb207>] ? cpuidle_enter_state+0xff/0x1f0 Sep 14 05:00:56 kernel: [3306540.492339] [<ffffffff816bb368>] cpuidle_enter+0x20/0x40 Sep 14 05:00:56 kernel: [3306540.492340] [<ffffffff8111f0d6>] call_cpuidle+0x3e/0x70 Sep 14 05:00:56 kernel: [3306540.492342] [<ffffffff8111f3ed>] cpu_startup_entry+0x175/0x230 Sep 14 05:00:56 kernel: [3306540.492344] [<ffffffff81092149>] start_secondary+0x1d1/0x290 Sep 14 05:00:56 kernel: [3306540.492346] PAX: size overflow detected in function br_dev_xmit include/linux/skbuff.h:2147 cicus.208_90 max, count: 1, decl: mac_header; num: 0; context: sk_buff; Sep 14 05:00:56 kernel: [3306540.495071] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.2-grsec #1 Sep 14 05:00:56 kernel: [3306540.495072] Hardware name: System manufacturer System Product Name/P8H77-I, BIOS 1001 02/01/2013 Sep 14 05:00:56 kernel: [3306540.495073] ffffffff81e048c7 0000000000000286 0000000000000000 ffff88041fb838b0 Sep 14 05:00:56 kernel: [3306540.495074] ffffffff813e35ab 0000000000000001 ffffffffa0410fe4 0000000000000863 Sep 14 05:00:56 kernel: [3306540.495076] ffff88041fb838e0 ffffffff8122b206 ffff88040c11f500 0000000100000040 Sep 14 05:00:56 kernel: [3306540.495077] Call Trace: Sep 14 05:00:56 kernel: [3306540.495078] <IRQ> [<ffffffff813e35ab>] dump_stack+0x4e/0x7b Sep 14 05:00:56 kernel: [3306540.495084] [<ffffffffa0410fe4>] ? br_dst_default_metrics+0x3ba4/0x4318 [bridge] Sep 14 05:00:56 kernel: [3306540.495086] [<ffffffff8122b206>] report_size_overflow+0x6e/0x90 Sep 14 05:00:56 kernel: [3306540.495089] [<ffffffffa03f94aa>] br_dev_xmit+0x202/0x2b0 [bridge] Sep 14 05:00:56 kernel: [3306540.495090] [<ffffffff81715c8c>] dev_hard_start_xmit+0x364/0x570 Sep 14 05:00:56 kernel: [3306540.495092] [<ffffffff81715494>] ? validate_xmit_skb.isra.123.part.124+0x1c/0x4b0 Sep 14 05:00:56 kernel: [3306540.495093] [<ffffffff8171660d>] __dev_queue_xmit+0x5f5/0x6c0 Sep 14 05:00:56 kernel: [3306540.495094] [<ffffffff817166ea>] dev_queue_xmit+0x12/0x30 Sep 14 05:00:56 kernel: [3306540.495096] [<ffffffff81721a4d>] neigh_resolve_output+0x135/0x200 Sep 14 05:00:56 kernel: [3306540.495098] [<ffffffff817defec>] ip6_finish_output2+0x194/0x4a0 Sep 14 05:00:56 kernel: [3306540.495099] [<ffffffff817de788>] ? ac6_proc_exit+0x30/0x30 Sep 14 05:00:56 kernel: [3306540.495100] [<ffffffff81756199>] ? nf_iterate+0x81/0xa0 Sep 14 05:00:56 kernel: [3306540.495102] [<ffffffff817e3652>] ip6_finish_output+0xaa/0x120 Sep 14 05:00:56 kernel: [3306540.495103] [<ffffffff817e189e>] ip6_output+0x66/0x110 Sep 14 05:00:56 kernel: [3306540.495104] [<ffffffff817e35a8>] ? ip6_fragment+0x1200/0x1200 Sep 14 05:00:56 kernel: [3306540.495106] [<ffffffff817de8b5>] ip6_forward_finish+0x3d/0x60 Sep 14 05:00:56 kernel: [3306540.495107] [<ffffffff817e1e38>] ip6_forward+0x4f0/0xa60 Sep 14 05:00:56 kernel: [3306540.495109] [<ffffffff817f10be>] ? ip6_route_input_lookup.isra.53+0x46/0x60 Sep 14 05:00:56 kernel: [3306540.495110] [<ffffffff817de878>] ? ndisc_hashfn+0x40/0x40 Sep 14 05:00:56 kernel: [3306540.495112] [<ffffffff817e4308>] ip6_rcv_finish+0x50/0xe0 Sep 14 05:00:56 kernel: [3306540.495113] [<ffffffff817e4b7f>] ipv6_rcv+0x357/0x6d0 Sep 14 05:00:56 kernel: [3306540.495114] [<ffffffff81828905>] ? tpacket_rcv+0x5d/0xb00 Sep 14 05:00:56 kernel: [3306540.495116] [<ffffffff811b7947>] ? __alloc_pages_nodemask+0x15f/0xb40 Sep 14 05:00:56 kernel: [3306540.495117] [<ffffffff817e42b8>] ? ip6_make_skb+0x1e0/0x1e0 Sep 14 05:00:56 kernel: [3306540.495119] [<ffffffff81711cc9>] __netif_receive_skb_core+0x381/0xce0 Sep 14 05:00:56 kernel: [3306540.495121] [<ffffffff8181f100>] ? ipv6_gro_receive+0x368/0xb90 Sep 14 05:00:56 kernel: [3306540.495123] [<ffffffff81712641>] __netif_receive_skb+0x19/0x80 Sep 14 05:00:56 kernel: [3306540.495124] [<ffffffff817126c6>] netif_receive_skb_internal+0x1e/0x90 Sep 14 05:00:56 kernel: [3306540.495126] [<ffffffff81713ba1>] napi_gro_receive+0x79/0xd0 Sep 14 05:00:56 kernel: [3306540.495128] [<ffffffffa00dc815>] rtl8169_poll+0x2fd/0x760 [r8169] Sep 14 05:00:56 kernel: [3306540.495130] [<ffffffff81712f99>] net_rx_action+0x341/0x510 Sep 14 05:00:56 kernel: [3306540.495131] [<ffffffff810df5ae>] __do_softirq+0x106/0x210 Sep 14 05:00:56 kernel: [3306540.495133] [<ffffffff810df808>] irq_exit+0x80/0x90 Sep 14 05:00:56 kernel: [3306540.495135] [<ffffffff81058949>] do_IRQ+0x51/0x100 Sep 14 05:00:56 kernel: [3306540.495136] [<ffffffff8184e40b>] common_interrupt+0x8b/0x8b Sep 14 05:00:56 kernel: [3306540.495137] <EOI> [<ffffffff816bb212>] ? cpuidle_enter_state+0x10a/0x1f0 Sep 14 05:00:56 kernel: [3306540.495140] [<ffffffff816bb207>] ? cpuidle_enter_state+0xff/0x1f0 Sep 14 05:00:56 kernel: [3306540.495141] [<ffffffff816bb368>] cpuidle_enter+0x20/0x40 Sep 14 05:00:56 kernel: [3306540.495143] [<ffffffff8111f0d6>] call_cpuidle+0x3e/0x70 Sep 14 05:00:56 kernel: [3306540.495144] [<ffffffff8111f3ed>] cpu_startup_entry+0x175/0x230 Sep 14 05:00:56 kernel: [3306540.495145] [<ffffffff81092149>] start_secondary+0x1d1/0x290 Sep 14 05:00:56 kernel: [3306540.495189] PAX: From xxx: kernel memory leak attempt detected from ffff880104d5f2c0 (radix_tree_node) (1294 bytes) Sep 14 05:00:56 kernel: [3306540.496583] CPU: 1 PID: 8219 Comm: qemu-system-x86 Not tainted 4.5.2-grsec #1 Sep 14 05:00:56 kernel: [3306540.496585] Hardware name: System manufacturer System Product Name/P8H77-I, BIOS 1001 02/01/2013 Sep 14 05:00:56 kernel: [3306540.496586] ffffffff81e048c7 0000000000000286 0000000000000000 ffffc9000d20bb20 Sep 14 05:00:56 kernel: [3306540.496588] ffffffff813e35ab ffff88041fa8d260 ffff880104d5f2c0 000000000000050e Sep 14 05:00:56 kernel: [3306540.496590] ffffc9000d20bb50 ffffffff8122b5e3 000000000000050e 0000000000000000 Sep 14 05:00:56 kernel: [3306540.496591] Call Trace: Sep 14 05:00:56 kernel: [3306540.496594] [<ffffffff813e35ab>] dump_stack+0x4e/0x7b Sep 14 05:00:56 kernel: [3306540.496597] [<ffffffff8122b5e3>] __check_object_size.part.50+0x10b/0x1f0 Sep 14 05:00:56 kernel: [3306540.496599] [<ffffffff8122b6f6>] __check_object_size+0x2e/0x50 Sep 14 05:00:56 kernel: [3306540.496601] [<ffffffff813fd99d>] copy_to_iter+0x1c5/0x820 Sep 14 05:00:56 kernel: [3306540.496603] [<ffffffff813fda2b>] ? copy_to_iter+0x253/0x820 Sep 14 05:00:56 kernel: [3306540.496605] [<ffffffff817028a2>] skb_copy_datagram_iter+0x5a/0x220 Sep 14 05:00:56 kernel: [3306540.496608] [<ffffffff815c7808>] tun_do_read+0x350/0x790 Sep 14 05:00:56 kernel: [3306540.496609] [<ffffffff815c7dc4>] tun_chr_read_iter+0x5c/0xb0 Sep 14 05:00:56 kernel: [3306540.496611] [<ffffffff81221999>] __vfs_read+0xf1/0x120 Sep 14 05:00:56 kernel: [3306540.496612] [<ffffffff81222c4f>] vfs_read+0xc7/0x250 Sep 14 05:00:56 kernel: [3306540.496614] [<ffffffff812241dd>] sys_read+0x45/0xb0 Sep 14 05:00:56 kernel: [3306540.496616] [<ffffffff8184d919>] entry_SYSCALL_64_fastpath+0x12/0x83 Sep 14 05:00:56 kernel: [3306540.496618] [<ffffffff8184d949>] ? entry_SYSCALL_64_fastpath+0x42/0x83 Sep 14 05:00:56 kernel: [3306540.496622] grsec: banning user with uid 1004 until system restart for suspicious kernel crash

uid 1004 was running qemu-system-x86 with a Linux VM, traffic including IPv6, connected to the host via a tap device plugged into a bridge.

Code pointers:

function ipv6_get_l4proto is http://lxr.free-electrons.com/source/ne ... ?v=4.5#L70 and line 83 is http://lxr.free-electrons.com/source/ne ... ?v=4.5#L83
Code: Select all
protoff = ipv6_skip_exthdr(skb, extoff, &nexthdr, &frag_off);

ipv6_skip_exthdr is http://lxr.free-electrons.com/source/ne ... ?v=4.5#L71
include/linux/skbuff.h:2147 is http://lxr.free-electrons.com/source/in ... =4.5#L2147
Code: Select all
static inline void skb_reset_mac_header(struct sk_buff *skb) { skb->mac_header = skb->data - skb->head; }
function __dev_queue_xmit is http://lxr.free-electrons.com/source/ne ... =4.5#L3273 and the first thing it does is:
Code: Select all
skb_reset_mac_header(skb);
function br_dev_xmit is http://lxr.free-electrons.com/source/ne ... ?v=4.5#L34 and it also calls skb_reset_mac_header on line 58 http://lxr.free-electrons.com/source/ne ... ?v=4.5#L58
radix_tree_node struct http://lxr.free-electrons.com/source/in ... ?v=4.5#L96

Let me know if you want me to provide the -fdump-tree-all -fdump-ipa-all for these objects.

Posted: **Thu Sep 15, 2016 9:04 am**

this is quite a bunch of problems

. i'd say that of the size overflow reports the first one is what matters, the others may just be cascading effects. this first one may be an upstream problem, you should ask them for clarification before we can do anything about it. what happens is that ipv6_skip_exthdr takes an int for its second parameter however an unsigned int is passed in when called from ipv6_get_l4proto. this uint comes from an uint parameter (nhoff) of ipv6_get_l4proto which is called indirectly by nf_conntrack_in which passes in the return value of skb_network_offset, an int itself to add even more int/uint conversions to the picture. the simplified code flow is something like this:

Code: Select all: ret = l3proto->get_l4proto(skb, skb_network_offset(skb),&dataoff, &protonum); static int ipv6_get_l4proto(const struct sk_buff *skb, unsigned int nhoff, unsigned int *dataoff, u_int8_t *protonum) unsigned int extoff = nhoff + sizeof(struct ipv6hdr); protoff = ipv6_skip_exthdr(skb, extoff, &nexthdr, &frag_off); int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,__be16 *frag_offp)

what can happen here is that skb_network_offset returns a negative number whose absolute value is larger than the size of ipv6hdr which the overflow plugin will catch since the resulting big positive value in extoff would be above INT_MAX. now whether this or something else happened i can't tell, you'd have to be able to reproduce this and print out the relevant variables to know for sure. it's at least clear that the ->get_l4proto callback doesn't expect negative nhoff values so some higher level invariant must have been violated here and at this point i'm out of my depth

.

as for the kernel memory leak attempt, that may very well be a consequence of the previous problem and i think it's a real kernel bug since a radix_tree_node should never ever be copied to userland, so i guess we're dealing with a heap overflow (well, overread) or a use-after-free bug here.

grsecurity forums

size overflow in ipv6_get_l4proto/br_dev_xmit, followed by memleak attempt

size overflow in ipv6_get_l4proto/br_dev_xmit, followed by memleak attempt

Re: size overflow in ipv6_get_l4proto/br_dev_xmit, followed by memleak attempt