From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0071C43381 for ; Thu, 21 Feb 2019 17:28:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6CE022083E for ; Thu, 21 Feb 2019 17:28:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KIHFf9W3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728382AbfBUR2l (ORCPT ); Thu, 21 Feb 2019 12:28:41 -0500 Received: from mail-ed1-f66.google.com ([209.85.208.66]:39465 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725831AbfBUR2l (ORCPT ); Thu, 21 Feb 2019 12:28:41 -0500 Received: by mail-ed1-f66.google.com with SMTP id p27so16284452edc.6 for ; Thu, 21 Feb 2019 09:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tARakXVVluKML+4dGuD9u/Rhmgp69XFE4ghja9QsOBw=; b=KIHFf9W35VUKs6TBEYsl4sRyVXMikINw1Lr6CDWXZEv2silAoBOkjmNz/TxHC3lGwd QUXuJZ/cARonb/PsT4hDf6vuSlloOGw9Uz8EiE98pHfffO4DcJQNDi8ZeUFCUaNHeMMX LarCkXXicFJoKeot2B26Ob6AT9fYMO4frsER5A1Soa/disPnuywUrpwnXy7CrmMlwl8J 8Qca/+xHpABbAgF8K0xgsj17/+s5ZhedMfh422+CcMVcHvsP6YatIg2v5YLE7UWANYee SHcVCkoTvOVfjPI2CbFT4YW9MBeMCcrTr5/2X+x2sGig1xMrv7R8TwlUyAcH751HRSvs VHeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tARakXVVluKML+4dGuD9u/Rhmgp69XFE4ghja9QsOBw=; b=SBzvvvt+qRQi2D0k+9+SAJnU0vyvtFB7mVNhw6J87P/F+k2LF3Z7IeqERr25LBLIRo nRODPwh17qQ5av4XPgy89O3vJhkHh0f5QjmA6/auAvEpqdwvMMWvvRCpt58Sp1XcKBww 2eTF7BUzYfzzlpFHqYXvt+G8n/Q1N7Ay+lc+crCpxR14ojuzsmQyp+qzvcBXqXs83zHb PpuAB6+8OYe/ycKQRtBjAiKPQ3LO7o0vghWtZs7tIgkqYAq3FlBoNsCwnK7tY8VCImSb c8UxhpgzYprRcys6l0USGVhl+TwwMflqdMV1inZCSm+jO4VjrYUh6ynabe+9F9T7Jci+ xiGw== X-Gm-Message-State: AHQUAubXBaTTi1AhERtntwK8YZaN1r6B2IFm5gKBH+EtLSq9fuMqax2D FQkbJXCsJ8p0/+QhV4phsFCjSUjGAUNN7dqPc0s= X-Google-Smtp-Source: AHgI3IZ2kAD92b9Ukl9024LgvMk67rMG+PqM6rzfDGw4oautTUKorzwOmaBp0e65YTgGbqTaOKtuJss9vvdZLv9uWPU= X-Received: by 2002:a50:a8c6:: with SMTP id k64mr30987174edc.138.1550770119098; Thu, 21 Feb 2019 09:28:39 -0800 (PST) MIME-Version: 1.0 References: <20190221123908.7196-1-maximmi@mellanox.com> <20190221123908.7196-2-maximmi@mellanox.com> In-Reply-To: <20190221123908.7196-2-maximmi@mellanox.com> From: Willem de Bruijn Date: Thu, 21 Feb 2019 12:28:03 -0500 Message-ID: Subject: Re: [PATCH net-next v2 1/7] net: Don't set transport offset to invalid value To: Maxim Mikityanskiy Cc: "David S. Miller" , Saeed Mahameed , Willem de Bruijn , Jason Wang , Eric Dumazet , "netdev@vger.kernel.org" , Eran Ben Elisha , Tariq Toukan Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Feb 21, 2019 at 7:40 AM Maxim Mikityanskiy 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 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/