On 03/18/2013 12:10 AM, David Miller wrote: > From: Jason Wang <jasow...@redhat.com> > Date: Fri, 15 Mar 2013 15:41:44 +0800 > >> Commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) tries to >> do >> precise packet len computation for GSO packets, but it does not check whether >> the packets were from untrusted source. This is wrong since: we haven't done >> header check before so both gso_segs and headers may not be correct. So this >> patch just bypass the precise pkt_len computation for packet from untrusted >> source (SKB_GSO_DODGY). >> >> Cc: Eric Dumazet <eduma...@google.com> >> Signed-off-by: Jason Wang <jasow...@redhat.com> > I do not think this is appropriate or even necessary. > > All the user can do by reporting an incorrect header size or GSO segs > is hurt himself, by making his traffic take more packet scheduler > quota.
I believe before doing header check for untrusted packets, the only thing we can trust is skb->len and that's we've used before 1def9238d4aa2. But after that, we're trying to use unchecked or meaningless value (e.g gso_segs were reset to zero in tun/macvtap/packet), and guest then can utilize this to result a very huge (-1U) pkt_len by filling evil value in the header. Can all kinds of packet scheduler survive this kinds of possible DOS? > > When we do precise accounting, it increases, never decreases, the > amount that a packet "costs" as far as the packet scheduler is > concerned. > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
