Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 2016-03-28 at 19:54 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 28 Mar 2016 13:51:46 -0700
>
> > On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote:
> >
> >> We have at least 384 bytes of padding in skb->head (this is struct
> >> skb_shared_info).
> >>
> >> Whatever garbage we might read, current code is fine.
> >>
> >> We have to deal with a false positive here.
> >
> > Very similar to the one fixed in
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=10ec9472f05b45c94db3c854d22581a20b97db41
>
> I don't see them as similar.
>
> The current options code we are talking about here never references
> past legitimate parts of the packet data. We always check 'length',
> and we never access past the boundary it describes.
>
> This was the entire point of my posting.
>
> Talking about padding, rather than the logical correctness of the
> code, is therefore a distraction I think :-)
Not really, we do read one out of bound byte David.
length = 1;
...
while (length > 0) {
int opcode = *ptr++; // Note that length is still 1
switch (opcode) {
...
default:
opsize = *ptr++; // Note that length is still 1
...
length -= opsize;
}
So we do read 2 bytes, while length was 1.
opsize definitely can read garbage.
Call it padding or redzone or whatever ;)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Eric Dumazet Date: Mon, 28 Mar 2016 13:51:46 -0700 > On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > >> We have at least 384 bytes of padding in skb->head (this is struct >> skb_shared_info). >> >> Whatever garbage we might read, current code is fine. >> >> We have to deal with a false positive here. > > Very similar to the one fixed in > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=10ec9472f05b45c94db3c854d22581a20b97db41 I don't see them as similar. The current options code we are talking about here never references past legitimate parts of the packet data. We always check 'length', and we never access past the boundary it describes. This was the entire point of my posting. Talking about padding, rather than the logical correctness of the code, is therefore a distraction I think :-) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Jan Engelhardt Date: Mon, 28 Mar 2016 22:20:39 +0200 (CEST) > > On Monday 2016-03-28 21:29, David Miller wrote: > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, > > length--; > > continue; > > default: > > +if (length < 2) > > +return; > > opsize = *ptr++; > > if (opsize < 2) /* "silly options" */ > > return; >> >>I'm trying to figure out how this can even matter. >>If we are in the loop, length is at least one. >>That means it is legal to read the opsize byte. > > Is that because the skbuff is always padded to a multiple of (at > least) two? No, it's because length is at least one, so we can read one byte. And then before we read more, we make sure length is at least opsize which is at least two. This has nothing to do with padding, and everything to do logically with the code. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 2016-03-28 at 23:11 +0200, Jozsef Kadlecsik wrote: > In net/netfilter/nf_conntrack_proto_tcp.c we copy the options into a > buffer with skb_header_pointer(), so it's not a false positive there and > the KASAN report referred to that part. > Although the out of bound could be one extra byte, if skb_header_bpointer() had to copy something (since it also might return a pointer inside skb->head) No arch would possibly fault here. So reading one byte on the stack is fooling KASAN, but no ill effect would actually happen. If the read byte is < 2, the function would return because of if (opsize < 2) return; If the read byte is >= 2, the function would return because of if (opsize > length) return; /* don't parse partial options */ (Since we care here of the case where length == 1) No big deal, it is probably better to 'fix' the code so that it pleases dynamic checkers. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 28 Mar 2016, Eric Dumazet wrote: > On Mon, 2016-03-28 at 22:20 +0200, Jan Engelhardt wrote: > > On Monday 2016-03-28 21:29, David Miller wrote: > > >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff > > >>> > > *skb, > > >>> > > length--; > > >>> > > continue; > > >>> > > default: > > >>> > > +if (length < 2) > > >>> > > +return; > > >>> > > opsize = *ptr++; > > >>> > > if (opsize < 2) /* "silly options" */ > > >>> > > return; > > > > > >I'm trying to figure out how this can even matter. > > >If we are in the loop, length is at least one. > > >That means it is legal to read the opsize byte. > > > > Is that because the skbuff is always padded to a multiple of (at > > least) two? Maybe such padding is explicitly foregone when ASAN is in > > place. After all, glibc, in userspace, is likely to do padding as > > well for malloc, and yet, ASAN catches these cases. There might be a TCP option combination, which is "properly" padded but broken, like (wscale, wscale-value, mss) where the mss-value is missing. > We have at least 384 bytes of padding in skb->head (this is struct > skb_shared_info). > > Whatever garbage we might read, current code is fine. > > We have to deal with a false positive here. In net/netfilter/nf_conntrack_proto_tcp.c we copy the options into a buffer with skb_header_pointer(), so it's not a false positive there and the KASAN report referred to that part. I thought it's valid for tcp_parse_options() too, but then I'm wrong so at least the part from the patch for tcp_input.c can be dropped. Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > We have at least 384 bytes of padding in skb->head (this is struct > skb_shared_info). > > Whatever garbage we might read, current code is fine. > > We have to deal with a false positive here. Very similar to the one fixed in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=10ec9472f05b45c94db3c854d22581a20b97db41 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 2016-03-28 at 22:20 +0200, Jan Engelhardt wrote: > On Monday 2016-03-28 21:29, David Miller wrote: > >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff > >>> > > *skb, > >>> > > length--; > >>> > > continue; > >>> > > default: > >>> > > +if (length < 2) > >>> > > +return; > >>> > > opsize = *ptr++; > >>> > > if (opsize < 2) /* "silly options" */ > >>> > > return; > > > >I'm trying to figure out how this can even matter. > >If we are in the loop, length is at least one. > >That means it is legal to read the opsize byte. > > Is that because the skbuff is always padded to a multiple of (at > least) two? Maybe such padding is explicitly foregone when ASAN is in > place. After all, glibc, in userspace, is likely to do padding as > well for malloc, and yet, ASAN catches these cases. We have at least 384 bytes of padding in skb->head (this is struct skb_shared_info). Whatever garbage we might read, current code is fine. We have to deal with a false positive here. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Monday 2016-03-28 21:29, David Miller wrote: >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, >>> > > length--; >>> > > continue; >>> > > default: >>> > > +if (length < 2) >>> > > +return; >>> > > opsize = *ptr++; >>> > > if (opsize < 2) /* "silly options" */ >>> > > return; > >I'm trying to figure out how this can even matter. >If we are in the loop, length is at least one. >That means it is legal to read the opsize byte. Is that because the skbuff is always padded to a multiple of (at least) two? Maybe such padding is explicitly foregone when ASAN is in place. After all, glibc, in userspace, is likely to do padding as well for malloc, and yet, ASAN catches these cases. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 2016-03-28 at 15:29 -0400, David Miller wrote: > From: Jozsef Kadlecsik > Date: Mon, 28 Mar 2016 18:48:51 +0200 (CEST) > > >> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, > >> > > length--; > >> > > continue; > >> > > default: > >> > > +if (length < 2) > >> > > +return; > >> > > opsize = *ptr++; > >> > > if (opsize < 2) /* "silly options" */ > >> > > return; > > I'm trying to figure out how this can even matter. > > If we are in the loop, length is at least one. > > That means it is legal to read the opsize byte. > > By the next check, opsize is at least 2. > > And then the very next line in this code makes sure length >= opsize: > > if (opsize > length) > return; /* don't parse partial options */ > > Therefore no out-of-range access is possible as far as I can see. Maybe use kasan_disable_current() and kasan_enable_current() to silence kasan ? Oh wait, these are not BH safe. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Jozsef Kadlecsik Date: Mon, 28 Mar 2016 18:48:51 +0200 (CEST) >> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, >> > > length--; >> > > continue; >> > > default: >> > > +if (length < 2) >> > > +return; >> > > opsize = *ptr++; >> > > if (opsize < 2) /* "silly options" */ >> > > return; I'm trying to figure out how this can even matter. If we are in the loop, length is at least one. That means it is legal to read the opsize byte. By the next check, opsize is at least 2. And then the very next line in this code makes sure length >= opsize: if (opsize > length) return; /* don't parse partial options */ Therefore no out-of-range access is possible as far as I can see. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, Mar 28, 2016 at 06:48:51PM +0200, Jozsef Kadlecsik wrote: > Hi David, Pablo, > > David, do you agree with the patch for net/ipv4/tcp_input.c? If yes, how > should I proceed? Should I send the whole patch to you or is it OK to send > to Pablo? Submit a formal patch and Cc: net...@vger.kernel.org and netfilter-devel@vger.kernel.org, then we can request David to ack this if he considers it fine or the other way around (I ack it he takes it). Thanks! -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
Hi David, Pablo, David, do you agree with the patch for net/ipv4/tcp_input.c? If yes, how should I proceed? Should I send the whole patch to you or is it OK to send to Pablo? Best regards, Jozsef On Mon, 28 Mar 2016, Baozeng Ding wrote: > > > On 2016/3/28 10:35, Baozeng Ding wrote: > > > > > > On 2016/3/28 6:25, Jozsef Kadlecsik wrote: > > > On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote: > > > > > > > On Sun, 27 Mar 2016, Baozeng Ding wrote: > > > > > > > > > The following program triggers stack-out-of-bounds in tcp_packet. The > > > > > kernel version is 4.5 (on Mar 16 commit > > > > > 09fd671ccb2475436bd5f597f751ca4a7d177aea). > > > > > Uncovered with syzkaller. Thanks. > > > > > > > > > > == > > > > > BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr > > > > > 8800a45df3c8 > > > > > Read of size 1 by task 0327/11132 > > > > > page:ea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0 > > > > > flags: 0x1fffc00() > > > > > page dumped because: kasan: bad access detected > > > > > CPU: 1 PID: 11132 Comm: 0327 Tainted: GB 4.5.0+ #12 > > > > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > > > > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 > > > > > 0001 8800a45df148 82945051 8800a45df1d8 > > > > > 8800a45df3c8 0027 0001 8800a45df1c8 > > > > > 81709f88 8800b4f7e3d0 0028 0286 > > > > > Call Trace: > > > > > [< inline >] __dump_stack /kernel/lib/dump_stack.c:15 > > > > > [] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51 > > > > > [< inline >] print_address_description > > > > > /kernel/mm/kasan/report.c:150 > > > > > [] kasan_report_error+0x4f8/0x530 > > > > > /kernel/mm/kasan/report.c:236 > > > > > [] ? skb_copy_bits+0x49d/0x6d0 > > > > > /kernel/net/core/skbuff.c:1675 > > > > > [< inline >] ? spin_lock_bh > > > > > /kernel/include/linux/spinlock.h:307 > > > > > [] ? tcp_packet+0x1c9/0x51c0 > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833 > > > > > [< inline >] kasan_report /kernel/mm/kasan/report.c:259 > > > > > [] __asan_report_load1_noabort+0x3e/0x40 > > > > > /kernel/mm/kasan/report.c:277 > > > > > [< inline >] ? tcp_sack > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 > > > > > [< inline >] ? tcp_in_window > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 > > > > > [] ? tcp_packet+0x4b77/0x51c0 > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 > > > > > [< inline >] tcp_sack > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 > > > > > [< inline >] tcp_in_window > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 > > > > > [] tcp_packet+0x4b77/0x51c0 > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 > > > > > [] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302 > > > > > [] ? tcp_new+0x1a4/0xc20 > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122 > > > > > [< inline >] ? build_report /kernel/include/net/netlink.h:499 > > > > > [] ? xfrm_send_report+0x426/0x450 > > > > > /kernel/net/xfrm/xfrm_user.c:3039 > > > > > [] ? tcp_new+0xc20/0xc20 > > > > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169 > > > > > [] ? init_conntrack+0xca/0x9e0 > > > > > /kernel/net/netfilter/nf_conntrack_core.c:972 > > > > > [] ? nf_conntrack_alloc+0x40/0x40 > > > > > /kernel/net/netfilter/nf_conntrack_core.c:903 > > > > > [] ? tcp_init_net+0x6e0/0x6e0 > > > > > /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137 > > > > > [] ? ipv4_get_l4proto+0x262/0x390 > > > > > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89 > > > > > [] ? nf_ct_get_tuple+0xaf/0x190 > > > > > /kernel/net/netfilter/nf_conntrack_core.c:197 > > > > > [] nf_conntrack_in+0x8ee/0x1170 > > > > > /kernel/net/netfilter/nf_conntrack_core.c:1177 > > > > > [] ? init_conntrack+0x9e0/0x9e0 > > > > > /kernel/net/netfilter/nf_conntrack_core.c:287 > > > > > [] ? ipt_do_table+0xa16/0x1260 > > > > > /kernel/net/ipv4/netfilter/ip_tables.c:423 > > > > > [] ? trace_hardirqs_on+0xd/0x10 > > > > > /kernel/kernel/locking/lockdep.c:2635 > > > > > [] ? __local_bh_enable_ip+0x6b/0xc0 > > > > > /kernel/kernel/softirq.c:175 > > > > > [] ? check_entry.isra.4+0x190/0x190 > > > > > /kernel/net/ipv6/netfilter/ip6_tables.c:594 > > > > > [] ? ip_reply_glue_bits+0xc0/0xc0 > > > > > /kernel/net/ipv4/ip_output.c:1530 > > > > > [] ipv4_conntrack_local+0x14e/0x1a0 > > > > > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161 > > > > > [] ? iptable_raw_hook+0x9d/0x1e0 > > > > > /kernel/net/ipv4/netfilter/iptable_raw.c:32 > > > > > [] nf_iterate+0x15d/0x230 > > > > > /kernel/net/netfilter/core.c:274 > > > > > [] ? nf_iterate+0x230/0x230 > > > > > /kernel/net/netfilter/core.c:268 > > > > > [] nf_hook_slow+0x1ad/0x310 > > > > > /kernel/net/netfilter/core.c:306 > > > > > [] ? nf_i
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On 2016/3/28 10:35, Baozeng Ding wrote: On 2016/3/28 6:25, Jozsef Kadlecsik wrote: On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote: On Sun, 27 Mar 2016, Baozeng Ding wrote: The following program triggers stack-out-of-bounds in tcp_packet. The kernel version is 4.5 (on Mar 16 commit 09fd671ccb2475436bd5f597f751ca4a7d177aea). Uncovered with syzkaller. Thanks. == BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr 8800a45df3c8 Read of size 1 by task 0327/11132 page:ea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x1fffc00() page dumped because: kasan: bad access detected CPU: 1 PID: 11132 Comm: 0327 Tainted: GB 4.5.0+ #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 0001 8800a45df148 82945051 8800a45df1d8 8800a45df3c8 0027 0001 8800a45df1c8 81709f88 8800b4f7e3d0 0028 0286 Call Trace: [< inline >] __dump_stack /kernel/lib/dump_stack.c:15 [] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51 [< inline >] print_address_description /kernel/mm/kasan/report.c:150 [] kasan_report_error+0x4f8/0x530 /kernel/mm/kasan/report.c:236 [] ? skb_copy_bits+0x49d/0x6d0 /kernel/net/core/skbuff.c:1675 [< inline >] ? spin_lock_bh /kernel/include/linux/spinlock.h:307 [] ? tcp_packet+0x1c9/0x51c0 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833 [< inline >] kasan_report /kernel/mm/kasan/report.c:259 [] __asan_report_load1_noabort+0x3e/0x40 /kernel/mm/kasan/report.c:277 [< inline >] ? tcp_sack /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 [< inline >] ? tcp_in_window /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 [] ? tcp_packet+0x4b77/0x51c0 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 [< inline >] tcp_sack /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 [< inline >] tcp_in_window /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 [] tcp_packet+0x4b77/0x51c0 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 [] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302 [] ? tcp_new+0x1a4/0xc20 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122 [< inline >] ? build_report /kernel/include/net/netlink.h:499 [] ? xfrm_send_report+0x426/0x450 /kernel/net/xfrm/xfrm_user.c:3039 [] ? tcp_new+0xc20/0xc20 /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169 [] ? init_conntrack+0xca/0x9e0 /kernel/net/netfilter/nf_conntrack_core.c:972 [] ? nf_conntrack_alloc+0x40/0x40 /kernel/net/netfilter/nf_conntrack_core.c:903 [] ? tcp_init_net+0x6e0/0x6e0 /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137 [] ? ipv4_get_l4proto+0x262/0x390 /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89 [] ? nf_ct_get_tuple+0xaf/0x190 /kernel/net/netfilter/nf_conntrack_core.c:197 [] nf_conntrack_in+0x8ee/0x1170 /kernel/net/netfilter/nf_conntrack_core.c:1177 [] ? init_conntrack+0x9e0/0x9e0 /kernel/net/netfilter/nf_conntrack_core.c:287 [] ? ipt_do_table+0xa16/0x1260 /kernel/net/ipv4/netfilter/ip_tables.c:423 [] ? trace_hardirqs_on+0xd/0x10 /kernel/kernel/locking/lockdep.c:2635 [] ? __local_bh_enable_ip+0x6b/0xc0 /kernel/kernel/softirq.c:175 [] ? check_entry.isra.4+0x190/0x190 /kernel/net/ipv6/netfilter/ip6_tables.c:594 [] ? ip_reply_glue_bits+0xc0/0xc0 /kernel/net/ipv4/ip_output.c:1530 [] ipv4_conntrack_local+0x14e/0x1a0 /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161 [] ? iptable_raw_hook+0x9d/0x1e0 /kernel/net/ipv4/netfilter/iptable_raw.c:32 [] nf_iterate+0x15d/0x230 /kernel/net/netfilter/core.c:274 [] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268 [] nf_hook_slow+0x1ad/0x310 /kernel/net/netfilter/core.c:306 [] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268 [] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268 [] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83 [] ? ip_idents_reserve+0x9f/0xf0 /kernel/net/ipv4/route.c:484 [< inline >] nf_hook_thresh /kernel/include/linux/netfilter.h:187 [< inline >] nf_hook /kernel/include/linux/netfilter.h:197 [] __ip_local_out+0x263/0x3c0 /kernel/net/ipv4/ip_output.c:104 [] ? ip_finish_output+0xd00/0xd00 /kernel/include/net/ip.h:322 [] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0 /kernel/net/ipv4/ip_output.c:1337 [] ? __ip_make_skb+0xfe6/0x1610 /kernel/net/ipv4/ip_output.c:1436 [] ip_local_out+0x2d/0x1c0 /kernel/net/ipv4/ip_output.c:113 [] ip_send_skb+0x3c/0xc0 /kernel/net/ipv4/ip_output.c:1443 [] ip_push_pending_frames+0x64/0x80 /kernel/net/ipv4/ip_output.c:1463 [< inline >] rcu_read_unlock /kernel/include/linux/rcupdate.h:922 [] raw_sendmsg+0x17bb/0x25c0 /kernel/net/ieee802154/socket.c:53 [] ? dst_output+0x190/0x190 /kernel/include/net/dst.h:492 [< inline >] ? trace_mm_page_alloc /kernel/include/trace/events/kmem.h:217 [] ? __alloc_pages_nodemask+0x559/0x16b0
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote: > On Sun, 27 Mar 2016, Baozeng Ding wrote: > > > The following program triggers stack-out-of-bounds in tcp_packet. The > > kernel version is 4.5 (on Mar 16 commit > > 09fd671ccb2475436bd5f597f751ca4a7d177aea). > > Uncovered with syzkaller. Thanks. > > > > == > > BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr > > 8800a45df3c8 > > Read of size 1 by task 0327/11132 > > page:ea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0 > > flags: 0x1fffc00() > > page dumped because: kasan: bad access detected > > CPU: 1 PID: 11132 Comm: 0327 Tainted: GB 4.5.0+ #12 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 > > 0001 8800a45df148 82945051 8800a45df1d8 > > 8800a45df3c8 0027 0001 8800a45df1c8 > > 81709f88 8800b4f7e3d0 0028 0286 > > Call Trace: > > [< inline >] __dump_stack /kernel/lib/dump_stack.c:15 > > [] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51 > > [< inline >] print_address_description /kernel/mm/kasan/report.c:150 > > [] kasan_report_error+0x4f8/0x530 > > /kernel/mm/kasan/report.c:236 > > [] ? skb_copy_bits+0x49d/0x6d0 > > /kernel/net/core/skbuff.c:1675 > > [< inline >] ? spin_lock_bh /kernel/include/linux/spinlock.h:307 > > [] ? tcp_packet+0x1c9/0x51c0 > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833 > > [< inline >] kasan_report /kernel/mm/kasan/report.c:259 > > [] __asan_report_load1_noabort+0x3e/0x40 > > /kernel/mm/kasan/report.c:277 > > [< inline >] ? tcp_sack > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 > > [< inline >] ? tcp_in_window > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 > > [] ? tcp_packet+0x4b77/0x51c0 > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 > > [< inline >] tcp_sack > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 > > [< inline >] tcp_in_window > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 > > [] tcp_packet+0x4b77/0x51c0 > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 > > [] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302 > > [] ? tcp_new+0x1a4/0xc20 > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122 > > [< inline >] ? build_report /kernel/include/net/netlink.h:499 > > [] ? xfrm_send_report+0x426/0x450 > > /kernel/net/xfrm/xfrm_user.c:3039 > > [] ? tcp_new+0xc20/0xc20 > > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169 > > [] ? init_conntrack+0xca/0x9e0 > > /kernel/net/netfilter/nf_conntrack_core.c:972 > > [] ? nf_conntrack_alloc+0x40/0x40 > > /kernel/net/netfilter/nf_conntrack_core.c:903 > > [] ? tcp_init_net+0x6e0/0x6e0 > > /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137 > > [] ? ipv4_get_l4proto+0x262/0x390 > > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89 > > [] ? nf_ct_get_tuple+0xaf/0x190 > > /kernel/net/netfilter/nf_conntrack_core.c:197 > > [] nf_conntrack_in+0x8ee/0x1170 > > /kernel/net/netfilter/nf_conntrack_core.c:1177 > > [] ? init_conntrack+0x9e0/0x9e0 > > /kernel/net/netfilter/nf_conntrack_core.c:287 > > [] ? ipt_do_table+0xa16/0x1260 > > /kernel/net/ipv4/netfilter/ip_tables.c:423 > > [] ? trace_hardirqs_on+0xd/0x10 > > /kernel/kernel/locking/lockdep.c:2635 > > [] ? __local_bh_enable_ip+0x6b/0xc0 > > /kernel/kernel/softirq.c:175 > > [] ? check_entry.isra.4+0x190/0x190 > > /kernel/net/ipv6/netfilter/ip6_tables.c:594 > > [] ? ip_reply_glue_bits+0xc0/0xc0 > > /kernel/net/ipv4/ip_output.c:1530 > > [] ipv4_conntrack_local+0x14e/0x1a0 > > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161 > > [] ? iptable_raw_hook+0x9d/0x1e0 > > /kernel/net/ipv4/netfilter/iptable_raw.c:32 > > [] nf_iterate+0x15d/0x230 /kernel/net/netfilter/core.c:274 > > [] ? nf_iterate+0x230/0x230 > > /kernel/net/netfilter/core.c:268 > > [] nf_hook_slow+0x1ad/0x310 > > /kernel/net/netfilter/core.c:306 > > [] ? nf_iterate+0x230/0x230 > > /kernel/net/netfilter/core.c:268 > > [] ? nf_iterate+0x230/0x230 > > /kernel/net/netfilter/core.c:268 > > [] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83 > > [] ? ip_idents_reserve+0x9f/0xf0 > > /kernel/net/ipv4/route.c:484 > > [< inline >] nf_hook_thresh /kernel/include/linux/netfilter.h:187 > > [< inline >] nf_hook /kernel/include/linux/netfilter.h:197 > > [] __ip_local_out+0x263/0x3c0 > > /kernel/net/ipv4/ip_output.c:104 > > [] ? ip_finish_output+0xd00/0xd00 > > /kernel/include/net/ip.h:322 > > [] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0 > > /kernel/net/ipv4/ip_output.c:1337 > > [] ? __ip_make_skb+0xfe6/0x1610 > > /kernel/net/ipv4/ip_output.c:1436 > > [] ip_local_out+0x2d/0x1c0 > > /kernel/net/ipv4/ip_output.c:113 > > [] ip_send_skb+0x3c/0xc0 /kernel/net/ipv4/ip_output.c:1443 > > [] ip_push_pending_frames+0x64/0x80 > > /kernel/net/
Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
On Sun, 27 Mar 2016, Baozeng Ding wrote: > The following program triggers stack-out-of-bounds in tcp_packet. The > kernel version is 4.5 (on Mar 16 commit > 09fd671ccb2475436bd5f597f751ca4a7d177aea). > Uncovered with syzkaller. Thanks. > > == > BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr > 8800a45df3c8 > Read of size 1 by task 0327/11132 > page:ea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0 > flags: 0x1fffc00() > page dumped because: kasan: bad access detected > CPU: 1 PID: 11132 Comm: 0327 Tainted: GB 4.5.0+ #12 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 > 0001 8800a45df148 82945051 8800a45df1d8 > 8800a45df3c8 0027 0001 8800a45df1c8 > 81709f88 8800b4f7e3d0 0028 0286 > Call Trace: > [< inline >] __dump_stack /kernel/lib/dump_stack.c:15 > [] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51 > [< inline >] print_address_description /kernel/mm/kasan/report.c:150 > [] kasan_report_error+0x4f8/0x530 > /kernel/mm/kasan/report.c:236 > [] ? skb_copy_bits+0x49d/0x6d0 > /kernel/net/core/skbuff.c:1675 > [< inline >] ? spin_lock_bh /kernel/include/linux/spinlock.h:307 > [] ? tcp_packet+0x1c9/0x51c0 > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833 > [< inline >] kasan_report /kernel/mm/kasan/report.c:259 > [] __asan_report_load1_noabort+0x3e/0x40 > /kernel/mm/kasan/report.c:277 > [< inline >] ? tcp_sack > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 > [< inline >] ? tcp_in_window > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 > [] ? tcp_packet+0x4b77/0x51c0 > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 > [< inline >] tcp_sack > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473 > [< inline >] tcp_in_window > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527 > [] tcp_packet+0x4b77/0x51c0 > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036 > [] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302 > [] ? tcp_new+0x1a4/0xc20 > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122 > [< inline >] ? build_report /kernel/include/net/netlink.h:499 > [] ? xfrm_send_report+0x426/0x450 > /kernel/net/xfrm/xfrm_user.c:3039 > [] ? tcp_new+0xc20/0xc20 > /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169 > [] ? init_conntrack+0xca/0x9e0 > /kernel/net/netfilter/nf_conntrack_core.c:972 > [] ? nf_conntrack_alloc+0x40/0x40 > /kernel/net/netfilter/nf_conntrack_core.c:903 > [] ? tcp_init_net+0x6e0/0x6e0 > /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137 > [] ? ipv4_get_l4proto+0x262/0x390 > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89 > [] ? nf_ct_get_tuple+0xaf/0x190 > /kernel/net/netfilter/nf_conntrack_core.c:197 > [] nf_conntrack_in+0x8ee/0x1170 > /kernel/net/netfilter/nf_conntrack_core.c:1177 > [] ? init_conntrack+0x9e0/0x9e0 > /kernel/net/netfilter/nf_conntrack_core.c:287 > [] ? ipt_do_table+0xa16/0x1260 > /kernel/net/ipv4/netfilter/ip_tables.c:423 > [] ? trace_hardirqs_on+0xd/0x10 > /kernel/kernel/locking/lockdep.c:2635 > [] ? __local_bh_enable_ip+0x6b/0xc0 > /kernel/kernel/softirq.c:175 > [] ? check_entry.isra.4+0x190/0x190 > /kernel/net/ipv6/netfilter/ip6_tables.c:594 > [] ? ip_reply_glue_bits+0xc0/0xc0 > /kernel/net/ipv4/ip_output.c:1530 > [] ipv4_conntrack_local+0x14e/0x1a0 > /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161 > [] ? iptable_raw_hook+0x9d/0x1e0 > /kernel/net/ipv4/netfilter/iptable_raw.c:32 > [] nf_iterate+0x15d/0x230 /kernel/net/netfilter/core.c:274 > [] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268 > [] nf_hook_slow+0x1ad/0x310 /kernel/net/netfilter/core.c:306 > [] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268 > [] ? nf_iterate+0x230/0x230 /kernel/net/netfilter/core.c:268 > [] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83 > [] ? ip_idents_reserve+0x9f/0xf0 > /kernel/net/ipv4/route.c:484 > [< inline >] nf_hook_thresh /kernel/include/linux/netfilter.h:187 > [< inline >] nf_hook /kernel/include/linux/netfilter.h:197 > [] __ip_local_out+0x263/0x3c0 > /kernel/net/ipv4/ip_output.c:104 > [] ? ip_finish_output+0xd00/0xd00 > /kernel/include/net/ip.h:322 > [] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0 > /kernel/net/ipv4/ip_output.c:1337 > [] ? __ip_make_skb+0xfe6/0x1610 > /kernel/net/ipv4/ip_output.c:1436 > [] ip_local_out+0x2d/0x1c0 /kernel/net/ipv4/ip_output.c:113 > [] ip_send_skb+0x3c/0xc0 /kernel/net/ipv4/ip_output.c:1443 > [] ip_push_pending_frames+0x64/0x80 > /kernel/net/ipv4/ip_output.c:1463 > [< inline >] rcu_read_unlock /kernel/include/linux/rcupdate.h:922 > [] raw_sendmsg+0x17bb/0x25c0 > /kernel/net/ieee802154/socket.c:53 > [] ? dst_output+0x190/0x190 /kernel/include/net/dst.h:492 > [< inline >] ? trace_mm_page_alloc > /kerne
