Re: [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver

[Sowmini Varadhan <sowmini.varadhan@oracle.com>]

On (01/27/17 09:37), Willem de Bruijn wrote:
> The immediate problem you were facing is that dev_validate_header
> accepts values smaller than hard_header_len even for protocols with
> fixed header lengths.

Yes!

> This is a consequence of that CAP_SYS_RAWIO branch. Without it,
> dev_validate_header would have correctly dropped your packet. That
> branch was added because there are tests that explicitly test bad
> input. Ideally, it would be behind sysctl and static key, but doing so
> might start failing active tests.

so this is quite perplexing to someone not familiar with ax25-like
interfaces.  In addition to the pointer you shared, I see
  https://www.spinics.net/lists/netdev/msg367358.html
where the quote is

" The AX.25 device level drivers are simply written to be robust if
  thrown partial frames.
   :
  The other thing that concerns me about this added logic in general is
  that you are also breaking test tools that want to deliberately send
  corrupt frames to certain classes of interface."

But how does the driver (even a robust one!) compute the L2 dst/src if the
application has not even passed down the minimum (which is 21 for ax25?)

Would it make sense to only do the CAP_SYS_RAWIO branch if the 
driver declares itself to have variable length L2 headers, via, e.g.,
some priv flag?

--Sowmini

BTW the http://comments.gmane.org/gmane.linux.network/401064 referred
to in commit 2793a23 is not accessible any more, not sure if its contents
were the same as the link you just shared.