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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 AF49DC43381 for ; Fri, 22 Mar 2019 04:15:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7863B218FE for ; Fri, 22 Mar 2019 04:15:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kAITLHlt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726079AbfCVEP3 (ORCPT ); Fri, 22 Mar 2019 00:15:29 -0400 Received: from mail-pf1-f174.google.com ([209.85.210.174]:32990 "EHLO mail-pf1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725981AbfCVEP3 (ORCPT ); Fri, 22 Mar 2019 00:15:29 -0400 Received: by mail-pf1-f174.google.com with SMTP id i19so624106pfd.0 for ; Thu, 21 Mar 2019 21:15:28 -0700 (PDT) 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=eJ8qdyJ5LQq/yrKML6Va67dcv/AFTPuC1rJkooFxu14=; b=kAITLHltuH1kdocIyuMmZvrdvPKBYb2VIGpUf4/ACpGXkFbi/vnrNG/4/Sy1pb8S1D txwSBhCLoYV0opZ4hHA4L7M2kYvAav3PzLOu2p5IH+KCEZQuDkAFrepcqeBPPMWi+L/7 Qig56pLByh3wl8iJYShvkrU8bsfmTzQrLYLCCXFZKNzdJItroU5rmg/DHxtEP2KO8Y03 MD2gKsMq7BXkspq7IvWY9RzQsNgm8R030UpYLTElwoLR2nphuQhh5qW6+fxiDhQgldg7 YjQo1z5471E25kWGn5OgfFjnBYc7bLowmIwG2+Q2Oo9sqLYGD0ETnLZhr3iP+RTLZUoe m7Cg== 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=eJ8qdyJ5LQq/yrKML6Va67dcv/AFTPuC1rJkooFxu14=; b=WoFicYughXhMe1R08EnuUl8o5mLSLauYIz3ZNGyAxeuNP2kvgW9l++05UE0l8yjMzh Yh8rkMTKPCXqwIlRLhe7Uqp3wMJQ+zFSRabhaEvvHYxfJmYLlWes0hRDPkKRmKY5yKt7 h4l5Pd45mSEgfCYk4khyRYYDOOkF1zn3skFf1m9k1psDLtEoATVRfC/MDZponQebsWGk Basi1+2dLRdpOlaJAiYnZ9DB7lNJfkCrHDZlGE78Am0BpA4aA+kVRLKQnqPOmUViAdYL gnfeTWJjUsIBp51au4tQeeH2KfCsMOftCWiJg91Lu2qgFoHdpQIFGlNaWB0KyD86FkN/ ly3g== X-Gm-Message-State: APjAAAUDh7sf8p8cE2CyBWdB1gxeqoH/hjxxmx8pmV7fXyyeyTWQXGU/ q7Ixi9XhBOIJfNr++hnn6DxU6GEPlMqovD1afM4= X-Google-Smtp-Source: APXvYqwH0b7Z7FvOQDV2BAVFMsSQ3E5NVIUvG6I9ofNPvihYOVShSDT697JGYCoejSCsjqLxOpYY6AFqxhWhBS3E5AE= X-Received: by 2002:a62:5c3:: with SMTP id 186mr6928609pff.35.1553228128611; Thu, 21 Mar 2019 21:15:28 -0700 (PDT) MIME-Version: 1.0 References: <20190319050824.24742-1-xiyou.wangcong@gmail.com> <20190319051739.kevpimikwthni65k@gondor.apana.org.au> <20190320053532.o7hawr2vkj6fxbv7@gondor.apana.org.au> <20190322041118.rlsfazd5athg2ucc@gondor.apana.org.au> In-Reply-To: <20190322041118.rlsfazd5athg2ucc@gondor.apana.org.au> From: Cong Wang Date: Thu, 21 Mar 2019 21:15:17 -0700 Message-ID: Subject: Re: [Patch net] xfrm: unify xfrm protocol checks To: Herbert Xu Cc: Linux Kernel Network Developers , syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.com, Steffen Klassert 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, Mar 21, 2019 at 9:11 PM Herbert Xu wrote: > > On Thu, Mar 21, 2019 at 09:06:05PM -0700, Cong Wang wrote: > > > > Good point. Replacing IPSEC_PROTO_ANY with zero should > > work too, but on the other hand, id.proto is still never allowed to > > be any other protocol than these 6 listed, no? > > It should never be IPSEC_PROTO_ANY since that's used as a wildcard. > > IOW if you're going to tighten up the check for the id.proto filed > in an actual state, you should distinguish between the case of an > ID that's used to add/modify a state vs. an ID that's be used to > query a state. IPSEC_PROTO_ANY and zero should be denied in the > first case and allowed in the second case. Yeah, this makes sense. Let me see if I can figure this out correctly. Thanks for the details!