| Message ID | 1369075650-21005-1-git-send-email-mjrosato@linux.vnet.ibm.com |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, 2013-05-20 at 14:47 -0400, Matthew Rosato wrote: > commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) does > not check to see if skb_transport_header is valid prior to using it in > qdisc_pkt_len_init(), which can lead to a kernel panic if > skb_transport_header is not valid but gso_size is nonzero. This patch > adds a check for skb_transport_header_was_set(). > > I managed to hit this scenario by driving a burst of traffic from a > qemu guest through a macvtap interface, causing a panic in the host kernel. > > Signed-off-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> > --- > net/core/dev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/core/dev.c b/net/core/dev.c > index fc1e289..5d0d3af 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -2596,7 +2596,7 @@ static void qdisc_pkt_len_init(struct sk_buff *skb) > /* To get more precise estimation of bytes sent on wire, > * we add to pkt_len the headers size of all segments > */ > - if (shinfo->gso_size) { > + if (shinfo->gso_size && skb_transport_header_was_set(skb)) { > unsigned int hdr_len; > u16 gso_segs = shinfo->gso_segs; > Have you tried a recent kernel ? I believe this was already discussed. Please fix macvtap instead if its still buggy. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/20/2013 02:58 PM, Eric Dumazet wrote: > On Mon, 2013-05-20 at 14:47 -0400, Matthew Rosato wrote: >> commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) does >> not check to see if skb_transport_header is valid prior to using it in >> qdisc_pkt_len_init(), which can lead to a kernel panic if >> skb_transport_header is not valid but gso_size is nonzero. This patch >> adds a check for skb_transport_header_was_set(). >> >> I managed to hit this scenario by driving a burst of traffic from a >> qemu guest through a macvtap interface, causing a panic in the host kernel. >> >> Signed-off-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> >> --- >> net/core/dev.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/core/dev.c b/net/core/dev.c >> index fc1e289..5d0d3af 100644 >> --- a/net/core/dev.c >> +++ b/net/core/dev.c >> @@ -2596,7 +2596,7 @@ static void qdisc_pkt_len_init(struct sk_buff *skb) >> /* To get more precise estimation of bytes sent on wire, >> * we add to pkt_len the headers size of all segments >> */ >> - if (shinfo->gso_size) { >> + if (shinfo->gso_size && skb_transport_header_was_set(skb)) { >> unsigned int hdr_len; >> u16 gso_segs = shinfo->gso_segs; >> > > Have you tried a recent kernel ? > > I believe this was already discussed. Mea Culpa. You are correct, I was missing a macvtap fix that already resolves this issue. For the sake of documentation, that fix is 9b4d669bc06c2 macvtap: set transport header before passing skb to lower device. Applied and verified that problem is resolved. You can consider this patch withdrawn. Thanks. > > Please fix macvtap instead if its still buggy. > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-05-20 at 16:32 -0400, Matthew Rosato wrote: > Mea Culpa. You are correct, I was missing a macvtap fix that already > resolves this issue. For the sake of documentation, that fix is > 9b4d669bc06c2 macvtap: set transport header before passing skb to lower > device. > > Applied and verified that problem is resolved. You can consider this > patch withdrawn. Thanks. Yes, and it was later a bit refined/cleaned-up commit 40893fd0fd4e0eda8c6 ("net: switch to use skb_probe_transport_header()") Thanks -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/core/dev.c b/net/core/dev.c index fc1e289..5d0d3af 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2596,7 +2596,7 @@ static void qdisc_pkt_len_init(struct sk_buff *skb) /* To get more precise estimation of bytes sent on wire, * we add to pkt_len the headers size of all segments */ - if (shinfo->gso_size) { + if (shinfo->gso_size && skb_transport_header_was_set(skb)) { unsigned int hdr_len; u16 gso_segs = shinfo->gso_segs;
commit 1def9238d4aa2 (net_sched: more precise pkt_len computation) does not check to see if skb_transport_header is valid prior to using it in qdisc_pkt_len_init(), which can lead to a kernel panic if skb_transport_header is not valid but gso_size is nonzero. This patch adds a check for skb_transport_header_was_set(). I managed to hit this scenario by driving a burst of traffic from a qemu guest through a macvtap interface, causing a panic in the host kernel. Signed-off-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)