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,
On (01/19/17 09:36), Paul Durrant wrote:
>
> Hi Sowmini,
>
> Sounds like a straightforward bug to me... netfront should be able
> to handle an empty skb and clearly, if it's relying on skb_headlen()
> being non-zero, that's not the case.
>
> Paul
I see. Seems like there are 2 things broken
On (01/19/17 11:31), Paul Durrant wrote:
> Sowmini,
>
> Yeah, it would be useful to verify any change fixes the particular
> issue you're seeing so please share the program. For the non-empty
> non-linear case I'd hope that catching this and doing a pull of some
> sensible amount of header (which
On (01/19/17 11:37), David Miller wrote:
>
> I thought we had code which made sure that at least a minimal
> link layer header was present in the SKB?
>
> Specifically I'm talking about the dev_validate_header() check.
> That is supposed to protect us from these kinds of situations.
ah, but I ru
On (01/19/17 13:47), Sowmini Varadhan wrote:
> > Specifically I'm talking about the dev_validate_header() check.
> > That is supposed to protect us from these kinds of situations.
>
> ah, but I run my pf_packet application as root, so I have
> capable(CAP_SYS_RAW
On (01/20/17 14:30), David Miller wrote:
>
> CAP_SYS_RAWIO or not, the contract we have with the device is that
> there will be at least enough bytes to cover a link layer header.
I see. If that's the case (for all the kernel-driver interfaces),
then the xen_netfront driver is probably not requi
On (01/25/17 15:06), Paul Durrant wrote:
>
> Making netfront cope with a fully non-linear skb looks like it would
> be quite intrusive and probably not worth it so I opted for just doing
> the ETH_HLEN pull-tail if necessary. Can you check it works for you?
I tested it, and it works fine, but n
