All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Maxim Mikityanskiy <maximmi@mellanox.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Willem de Bruijn <willemb@google.com>,
	Jason Wang <jasowang@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Eran Ben Elisha <eranbe@mellanox.com>,
	Tariq Toukan <tariqt@mellanox.com>
Subject: Re: [PATCH net-next v2 1/7] net: Don't set transport offset to invalid value
Date: Thu, 21 Feb 2019 12:28:03 -0500	[thread overview]
Message-ID: <CAF=yD-KhWPL5JewXMxsikRNYCL88GZqdwrGvNNAm10N-NNaocw@mail.gmail.com> (raw)
In-Reply-To: <20190221123908.7196-2-maximmi@mellanox.com>

On Thu, Feb 21, 2019 at 7:40 AM Maxim Mikityanskiy <maximmi@mellanox.com> wrote:
>
> If the socket was created with socket(AF_PACKET, SOCK_RAW, 0),
> skb->protocol will be unset, __skb_flow_dissect() will fail, and
> skb_probe_transport_header() will fall back to the offset_hint, making
> the resulting skb_transport_offset incorrect.
>
> If, however, there is no transport header in the packet,
> transport_header shouldn't be set to an arbitrary value.
>
> Fix it by leaving the transport offset unset if it couldn't be found, to
> be explicit rather than to fill it with some wrong value. It changes the
> behavior, but if some code relied on the old behavior, it would be
> broken anyway, as the old one is incorrect.
>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>

qdisc_pkt_len_init also expects skb_transport_header(skb) to always be
set for gso packets.

Once net is merged into net-next, commit d5be7f632bad ("net: validate
untrusted gso packets without csum offload") will ensure that packets
that fail flow dissection do not make it into the stack. But we have
to skip dissection in some cases, like tun [1].

I think we need to add a check in qdisc_pkt_len_init to skip the gso
size estimation branch if !skb_transport_header_was_set(skb).

Otherwise this patch set looks good to me. To avoid resubmitting
everything we can fix up the qdisc_pkt_len_init in a follow-up, in
which case I'm happy to add my Acked-by to this series.

[1] http://patchwork.ozlabs.org/patch/1044429/

  reply	other threads:[~2019-02-21 17:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 12:39 [PATCH net-next v2 0/7] AF_PACKET transport_offset fix Maxim Mikityanskiy
2019-02-21 12:39 ` [PATCH net-next v2 1/7] net: Don't set transport offset to invalid value Maxim Mikityanskiy
2019-02-21 17:28   ` Willem de Bruijn [this message]
2019-02-22 12:30     ` Maxim Mikityanskiy
2019-02-22 14:16       ` Willem de Bruijn
2019-02-21 12:39 ` [PATCH net-next v2 2/7] net: Introduce parse_protocol header_ops callback Maxim Mikityanskiy
2019-02-21 12:39 ` [PATCH net-next v2 3/7] net/ethernet: Add parse_protocol header_ops support Maxim Mikityanskiy
2019-02-21 12:40 ` [PATCH net-next v2 4/7] net/packet: Ask driver for protocol if not provided by user Maxim Mikityanskiy
2019-02-21 12:40 ` [PATCH net-next v2 5/7] net/packet: Remove redundant skb->protocol set Maxim Mikityanskiy
2019-02-21 12:40 ` [PATCH net-next v2 6/7] net/mlx5e: Remove the wrong assumption about transport offset Maxim Mikityanskiy
2019-02-21 12:40 ` [PATCH net-next v2 7/7] net/mlx5e: Trust kernel regarding " Maxim Mikityanskiy
2019-02-22 12:55 ` [PATCH net-next] net: Skip GSO length estimation if transport header is not set Maxim Mikityanskiy
2019-02-22 14:19   ` Willem de Bruijn
2019-02-24 20:41   ` David Miller
2019-02-22 14:20 ` [PATCH net-next v2 0/7] AF_PACKET transport_offset fix Willem de Bruijn
2019-02-22 20:55   ` David Miller

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='CAF=yD-KhWPL5JewXMxsikRNYCL88GZqdwrGvNNAm10N-NNaocw@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eranbe@mellanox.com \
    --cc=jasowang@redhat.com \
    --cc=maximmi@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=tariqt@mellanox.com \
    --cc=willemb@google.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.