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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
