[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170118192528.GA6847@char.us.oracle.com>
Date: Wed, 18 Jan 2017 14:25:28 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Sowmini Varadhan <sowmini.varadhan@...cle.com>,
wei.liu2@...rix.com, paul.durrant@...rix.com
Cc: netdev@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: Re: [Xen-devel] xennet_start_xmit assumptions
On Wed, Jan 18, 2017 at 10:31:32AM -0500, Sowmini Varadhan wrote:
> As I was playing around with pf_packet, I accidentally wrote
> a buggy application program that bzero'ed the msghdr, then set
> up the msg_name, msg_namelen correctly, and then did a sendmsg
> on the pf_packet/SOCK_RAW fd.
>
> This causes packet_snd to set up an skb with a lot of issues,
> e.g., skb->len = 0, skb_headlen(skb) is 0, etc. I think we can/should
> drop the packet in packet_snd if the skb->len is 0, but there
> may be other driver bugs going on:
>
> Turns out that ixgbe and sunvnet handle this problematic
> skb correctly (they drop it and system remains stable),
> but it creates a panic in xen_netfront (xennet_start_xmit()
> hits a null pointer deref when xennet_make_first_txreq() returns
> NULL)
>
> I'm new to the xen driver code, so I'm hoping that
> the experts can comment here: reading the code in xennet_start_xmit,
> it seems like it mandatorily requires the skb_headlen() to be
> non-zero in order to create the first_tx? That may not always be
> true, how does the code recover for purely non-linear skbs?
>
> --Sowmini
CC-ing the two folks from the MAINTAINERS file.
Powered by blists - more mailing lists