size overflow detected in function xfrm6_transport_output

[marcan]

I'm getting this while messing around with IPv6+IPsec. Oddly enough it doesn't seem to happen on the box that I'm talking to, even though both are running the same kernel version (4.4.5-hardened) with similar (but not identical) configs, and with CONFIG_PAX_SIZE_OVERFLOW. The box without the issue has a more complex network config though (involving bridges and VLANs), so perhaps that code path doesn't trigger the issue.

Any idea if this is a false positive or a real issue? skb_set_mac_header seems to be deliberately called with negative arguments often, so I'm thinking that might cause some confusion.

Code: Select all

[ 1540.625272] PAX: size overflow detected in function xfrm6_transport_output net/ipv6/xfrm6_mode_transport.c:31 cicus.35_70 min, count: 14, decl: mac_header; num: 0; context: sk_buff;
[ 1540.625284] CPU: 0 PID: 7378 Comm: ping6 Not tainted 4.4.5-hardened #1
[ 1540.625285] Hardware name: CLEVO                             P151EMx/P151EMx, BIOS 4.6.5 04/23/2012
[ 1540.625287]  0000000000000000 ffffffff81386801 ffff88082f20cfe0 ffffffffa0002830
[ 1540.625291]  000000000000001f ffffffff811f327d 0000000000000048 ffffc9000f363b70
[ 1540.625294]  ffff880757c7ea00 ffff8807fd17f448 ffffffffa000220f 0000000000000286
[ 1540.625297] Call Trace:
[ 1540.625305]  [<ffffffff81386801>] ? dump_stack+0x47/0x66
[ 1540.625311]  [<ffffffffa0002830>] ? xfrm6_transport_exit+0x1d1/0x67b [xfrm6_mode_transport]
[ 1540.625315]  [<ffffffff811f327d>] ? report_size_overflow+0x5d/0x70
[ 1540.625318]  [<ffffffffa000220f>] ? xfrm6_transport_output+0x20f/0x530 [xfrm6_mode_transport]
[ 1540.625324]  [<ffffffff816ea427>] ? xfrm_output_resume+0x297/0x4f0
[ 1540.625329]  [<ffffffffa0bac3d4>] ? ipv6_confirm+0x94/0x130 [nf_conntrack_ipv6]
[ 1540.625333]  [<ffffffff81672154>] ? nf_iterate+0x54/0x70
[ 1540.625337]  [<ffffffff81731a2e>] ? xfrm6_output+0x8e/0xa0
[ 1540.625341]  [<ffffffff81731620>] ? xfrm6_local_rxpmtu+0x70/0x70
[ 1540.625343]  [<ffffffff816f8aa9>] ? ip6_send_skb+0x19/0x60
[ 1540.625347]  [<ffffffff817176ab>] ? rawv6_sendmsg+0xadb/0xe00
[ 1540.625350]  [<ffffffff81716130>] ? rawv6_recvmsg+0x390/0x390
[ 1540.625355]  [<ffffffff81115eeb>] ? remove_wait_queue+0x1b/0x30
[ 1540.625358]  [<ffffffff81451299>] ? n_tty_write+0x289/0x4f0
[ 1540.625361]  [<ffffffff81454fe9>] ? copy_termios+0x19/0x70
[ 1540.625363]  [<ffffffff81455cd5>] ? tty_mode_ioctl+0x465/0x810
[ 1540.625368]  [<ffffffff81613ebe>] ? sock_sendmsg+0xe/0x20
[ 1540.625371]  [<ffffffff816154b7>] ? SyS_sendto+0xd7/0x150
[ 1540.625375]  [<ffffffff810e8661>] ? recalc_sigpending+0x11/0x40
[ 1540.625378]  [<ffffffff810e9127>] ? __set_task_blocked+0x27/0x70
[ 1540.625382]  [<ffffffff810fc6df>] ? __commit_creds+0x4f/0x260
[ 1540.625386]  [<ffffffff8174a11b>] ? entry_SYSCALL_64_fastpath+0x12/0x6e


[PaX Team]

given that we encountered the same issue on the ipv4 side, it's probably the same gcc induced intentional overflow. you can try to add __intentional_overflow(0) to xfrm6_transport_output that should disable the instrumentation in the function.

[marcan]

Thanks for confirming the issue. Adding __intentional_overflow(0) does indeed fix things.