grsecurity forums

Running patch 3.1-4.8.17-201701090823 (linux-grsec kernel in Arch Linux), I see this panic when setting up a tc qdisc and send traffic through the interface. It looks like it might be related to this issue, though possible a different instantiation of it since the patch mentioned in this post is still in the latest patch I have used: http://forums.grsecurity.net/viewtopic.php?f=3&t=4438

Code: Select all

[ 1187.736468] PAX: size overflow detected in function tbf_enqueue net/sched/sch_tbf.c:191 cicus.161_140 min, count: 30, decl: qdisc_tree_reduce_backlog; num: 2; context: fndecl;
[ 1187.737208] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.17.r201701090823-1-grsec #1
[ 1187.737216] Hardware name: ZOTAC XXXXXX/XXXXXX, BIOS B301P017 04/06/2016
[ 1187.737230]  f360169500000002 f3601695ac9346ff 0000000000000286 0000000000000000
[ 1187.737254]  ffffc9000000b660 ffffffff8134249f 0000000000000006 f3601695ac9346ff
[ 1187.737273]  ffffffffa0795976 00000000000000bf ffffc9000000b690 ffffffff811fdc6c
[ 1187.737305] Call Trace:
[ 1187.737312]  <IRQ>  [<ffffffff8134249f>] dump_stack+0x76/0xc7
[ 1187.737366]  [<ffffffffa0795976>] ? tbf_module_exit+0x59e/0x80a [sch_tbf]
[ 1187.737381]  [<ffffffff811fdc6c>] report_size_overflow+0x6c/0x90
[ 1187.737398]  [<ffffffffa07953cb>] tbf_enqueue+0x2cb/0x2d8 [sch_tbf]
[ 1187.737429]  [<ffffffff8156712f>] __dev_queue_xmit+0x22f/0x710
[ 1187.737441]  [<ffffffff81567622>] dev_queue_xmit+0x12/0x30
[ 1187.737455]  [<ffffffff815bed61>] ip_finish_output2+0x281/0x380
[ 1187.737468]  [<ffffffff815c1338>] ip_finish_output+0x168/0x220
[ 1187.737482]  [<ffffffff815b18d4>] ? nf_hook_slow+0x94/0xf0
[ 1187.737495]  [<ffffffff815c11d0>] ? ip_fragment.constprop.5+0xb0/0xb0
[ 1187.737507]  [<ffffffff815c20d4>] ip_output+0x94/0x130
[ 1187.737525]  [<ffffffffa060a102>] ? iptable_filter_table_init+0x12/0x40 [iptable_filter]
[ 1187.737538]  [<ffffffff815c11d0>] ? ip_fragment.constprop.5+0xb0/0xb0
[ 1187.737551]  [<ffffffff815bcd63>] ip_forward_finish+0x63/0x90
[ 1187.737562]  [<ffffffff815bcd00>] ? ip_frag_mem+0x60/0x60
[ 1187.737583]  [<ffffffff815bd16c>] ip_forward+0x3dc/0x510
[ 1187.737595]  [<ffffffff815bcd00>] ? ip_frag_mem+0x60/0x60
[ 1187.737607]  [<ffffffff815ba3d1>] ip_rcv_finish+0x241/0x460
[ 1187.737619]  [<ffffffff815ba190>] ? ip_local_deliver_finish+0x2c0/0x2c0
[ 1187.737630]  [<ffffffff815babd3>] ip_rcv+0x353/0x600
[ 1187.737641]  [<ffffffff81566d02>] ? dev_hard_start_xmit+0x52/0x140
[ 1187.737654]  [<ffffffff815ba190>] ? ip_local_deliver_finish+0x2c0/0x2c0
[ 1187.737669]  [<ffffffff8155fb4a>] __netif_receive_skb_core+0x60a/0xdd0
[ 1187.737682]  [<ffffffff815bec9d>] ? ip_finish_output2+0x1bd/0x380
[ 1187.737721]  [<ffffffffa0201270>] ? br_port_flags_change+0x40/0x40 [bridge]
[ 1187.737741]  [<ffffffff8156330b>] __netif_receive_skb+0x1b/0x80
[ 1187.737774]  [<ffffffffa0201270>] ? br_port_flags_change+0x40/0x40 [bridge]
[ 1187.737786]  [<ffffffff815633f6>] netif_receive_skb_internal+0x86/0xe0
[ 1187.737798]  [<ffffffff815c20d4>] ? ip_output+0x94/0x130
[ 1187.737809]  [<ffffffff81563460>] netif_receive_skb+0x10/0x30
[ 1187.737842]  [<ffffffffa0201280>] br_netif_receive_skb+0x10/0x30 [bridge]
[ 1187.737883]  [<ffffffffa0201385>] br_pass_frame_up+0xe5/0x1b0 [bridge]
[ 1187.737917]  [<ffffffffa020168a>] br_handle_frame_finish+0x23a/0x680 [bridge]
[ 1187.737953]  [<ffffffffa0201450>] ? br_pass_frame_up+0x1b0/0x1b0 [bridge]
[ 1187.737992]  [<ffffffffa0201daf>] br_handle_frame+0x1df/0x380 [bridge]
[ 1187.738007]  [<ffffffff81543f2c>] ? skb_gro_receive+0x57c/0xc30
[ 1187.738041]  [<ffffffffa0201bd0>] ? br_handle_local_finish+0x50/0x50 [bridge]
[ 1187.738056]  [<ffffffff8155f8fc>] __netif_receive_skb_core+0x3bc/0xdd0
[ 1187.738069]  [<ffffffff8156330b>] __netif_receive_skb+0x1b/0x80
[ 1187.738087]  [<ffffffff815633f6>] netif_receive_skb_internal+0x86/0xe0
[ 1187.738102]  [<ffffffff81607f7a>] ? inet_gro_complete+0xba/0x110
[ 1187.738113]  [<ffffffff8156352b>] napi_gro_complete+0xab/0xe0
[ 1187.738123]  [<ffffffff815635b0>] napi_gro_flush+0x50/0x90
[ 1187.738134]  [<ffffffff81563656>] napi_complete_done+0x66/0xc0
[ 1187.738158]  [<ffffffffa05e96ee>] rtl8169_poll+0x8e/0x6a0 [r8169]
[ 1187.738170]  [<ffffffff8156576c>] net_rx_action+0x24c/0x340
[ 1187.738185]  [<ffffffff81079c16>] __do_softirq+0x106/0x240
[ 1187.738203]  [<ffffffff81079eeb>] irq_exit+0x9b/0xb0
[ 1187.738217]  [<ffffffff810211e1>] do_IRQ+0x51/0x100
[ 1187.738230]  [<ffffffff816cc8ce>] common_interrupt+0x8e/0x8e
[ 1187.738234]  <EOI>  [<ffffffff81517ddd>] ? cpuidle_enter_state+0x11d/0x200
[ 1187.738270]  [<ffffffff81517dcf>] ? cpuidle_enter_state+0x10f/0x200
[ 1187.738283]  [<ffffffff81517f40>] cpuidle_enter+0x20/0x40
[ 1187.738297]  [<ffffffff810c1e95>] call_cpuidle+0x35/0x70
[ 1187.738310]  [<ffffffff810c2228>] cpu_startup_entry+0x1c8/0x280
[ 1187.738325]  [<ffffffff81049a60>] ? lapic_update_tsc_freq+0x30/0x30
[ 1187.738340]  [<ffffffff810520b0>] ? flat_init_apic_ldr+0xc0/0xc0
[ 1187.738352]  [<ffffffff81046f2d>] start_secondary+0x1fd/0x250



are you compiling with gcc-6 by any chance? it seems that the forwprop pass got smarter and it undoes the source change now so we're back at the original problem unfortunately... not sure what we can do about it but till then you can disable the PAX_SIZE_OVERFLOW_EXTRA option.

It's gcc 6.2.1.

after having looked at the options we decided to disable instrumentation for qdisc_tree_reduce_backlog altogether in the next patch (i.e., its second parameter will no longer be tracked and instrumented).

I am currently booting with "pax_size_overflow_report_only" set to work around the kernel panic (yes, probably a heavy hammer), with the next patch I should be able to remove that option from the cmdline and not experience the panic when using tc qdisc?

yes, that's the idea though note that similar code constructs may exist elsewhere and can trigger a size overflow report, we'll see.