All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.