From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver
Date: Thu, 26 Jan 2017 21:08:36 -0500 [thread overview]
Message-ID: <20170127020836.GH29475@oracle.com> (raw)
In-Reply-To: <CAF=yD-L66dFV64fx21A3059LRiot_-j0Ykp9GkRFwf52099upQ@mail.gmail.com>
On (01/26/17 19:08), Willem de Bruijn wrote:
>
> Thanks for the context. ax25_addr_parse doesn't adjust length, it only
> verifies that the contents of the variable length header matches
> protocol spec. I don't think that it or the .validate callback have to
> be modified to return length.
Yes, I noticed that too, but my reading of ax25_addr_parse
was that it checks to see that a sane L2 header has been
passed in, and if that (sane-header) is the case, it
returns pointer to the start of data. Thus the returned
(non-null) pointer minus start should tell you the "real"
header length- is my understanding correct?
> To ensure that skb_headlen(skb) is at least a valid header length even
> when CAP_SYS_RAWIO bypasses validation perhaps revise
> dev_validate_header to take an additional skb->len parameter and
> call skb_put directly from inside that branch.
but when I scanned the af_packet code (which appears to
be the only thing that uses dev_validate_header today)
it already sets up the skb->data and ->len pointers up
correctly (based on len, hard_header_len etc) *before*
calling dev_validate_header, so the additional skb_put
is not needed?
still havent googled up prior discussions that led
to dev_validate_header- will probably do that tomorrow AM.
--Sowmini
next prev parent reply other threads:[~2017-01-27 2:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-24 16:11 [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver Sowmini Varadhan
2017-01-25 17:45 ` David Miller
2017-01-26 20:21 ` Willem de Bruijn
2017-01-26 21:37 ` Sowmini Varadhan
2017-01-27 0:08 ` Willem de Bruijn
2017-01-27 2:08 ` Sowmini Varadhan [this message]
2017-01-27 14:37 ` Willem de Bruijn
2017-01-27 15:11 ` Sowmini Varadhan
2017-01-27 15:28 ` Willem de Bruijn
2017-01-27 17:03 ` Sowmini Varadhan
2017-01-27 19:29 ` Willem de Bruijn
2017-01-27 20:06 ` Sowmini Varadhan
2017-01-27 20:51 ` Willem de Bruijn
2017-01-27 21:58 ` Sowmini Varadhan
2017-01-28 0:19 ` Willem de Bruijn
2017-01-30 16:26 ` Sowmini Varadhan
2017-01-30 16:41 ` David Miller
2017-02-07 20:51 ` Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170127020836.GH29475@oracle.com \
--to=sowmini.varadhan@oracle.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.