Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7211520yba; Thu, 2 May 2019 06:16:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRWtKBLSRNmynir1JAyqT/xkleZXm7hMVxLswruOdiQ9MrUM1XiOmBiGpeGo8sGBiH7z7v X-Received: by 2002:a17:902:7c01:: with SMTP id x1mr3603820pll.299.1556802980829; Thu, 02 May 2019 06:16:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556802980; cv=none; d=google.com; s=arc-20160816; b=yRUtfI0AfCk2OyFzXTRXTFaxYrJb4qnANGnnchObQMEqj2li9ADxcAj6vnaH8yKW0t scaKWr2q1V7hRe5RYAXuKlgk64XDse1TARNHbf/ycgSQmTSw6awqjgMBlhUj3evDB/7/ 9oEX4SRKXHbeiZjrnjtjMqE4zYsHPeoc9GUug+m/IDEcfX/kXZ3O+QZaYt8cuXlBozt4 psGHWPbAsePtUchANNUTxiV023CaWWpXgUPayuvDdwzdoPoCBAJaUxpuuxCzwLrfXlv6 O1JJehBXL2ANuQM3PgyEz+B1UyV0k4c2ACLaFckcos/hQ+s9h4RKw/PPT2c2sKvjqwQb z3gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=XY6tX/28eFAQgBig7w7VsMI8sDMSsqvCJ3mPL2VWTKc=; b=ZpjQzTvgAGbxhFXelU0/CXbzb8iENGHwAtbi9qI8ONFFcK4L8lHag22yct6eT5ULnj Y9Ebjh16qCD6BN3uBCxp6C5qfyDJZMb0zVG0Uc+zJj+yWRbLkqCyEyX1mYvi/+MQ8DxV 2Ek4kuVywAd0pYctabj+WNzEouLVllHf3A2NgQ2JrJma9oTi61B0GU1iCl8F3dImVY2y Aa7FzbjSg4UHtYMX9OJ1N61Os4mjtTNQ6xPU3T3gPsOE/DjkY1v1RplYVoWzle/2zrb8 DCXj6B34sJZSk6DBaFbPaEgqvE4fH1gJQLsylImloV5EJT071D1A26b7DQNAKjnPJX6N z5uQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d21si42889887pgh.255.2019.05.02.06.16.04; Thu, 02 May 2019 06:16:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726434AbfEBNOT (ORCPT + 99 others); Thu, 2 May 2019 09:14:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:38550 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726197AbfEBNOS (ORCPT ); Thu, 2 May 2019 09:14:18 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A1BE5AEFD; Thu, 2 May 2019 13:14:16 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 4FEBFE0117; Thu, 2 May 2019 15:14:16 +0200 (CEST) Date: Thu, 2 May 2019 15:14:16 +0200 From: Michal Kubecek To: Johannes Berg Cc: "David S. Miller" , "netdev@vger.kernel.org" , David Ahern , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH net-next 3/3] netlink: add validation of NLA_F_NESTED flag Message-ID: <20190502131416.GE21672@unicorn.suse.cz> References: <75a0887b3eb70005c272685d8ef9a712f37d7a54.1556798793.git.mkubecek@suse.cz> <3e8291cb2491e9a1830afdb903ed2c52e9f7475c.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e8291cb2491e9a1830afdb903ed2c52e9f7475c.camel@sipsolutions.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 02, 2019 at 02:54:56PM +0200, Johannes Berg wrote: > On Thu, 2019-05-02 at 12:48 +0000, Michal Kubecek wrote: > > Add new validation flag NL_VALIDATE_NESTED which adds three consistency > > checks of NLA_F_NESTED_FLAG: > > > > - the flag is set on attributes with NLA_NESTED{,_ARRAY} policy > > - the flag is not set on attributes with other policies except NLA_UNSPEC > > - the flag is set on attribute passed to nla_parse_nested() > > Looks good to me! > > > @@ -415,7 +418,8 @@ enum netlink_validation { > > #define NL_VALIDATE_STRICT (NL_VALIDATE_TRAILING |\ > > NL_VALIDATE_MAXTYPE |\ > > NL_VALIDATE_UNSPEC |\ > > - NL_VALIDATE_STRICT_ATTRS) > > + NL_VALIDATE_STRICT_ATTRS |\ > > + NL_VALIDATE_NESTED) > > This is fine _right now_, but in general we cannot keep adding here > after the next release :-) Right, that's why I would like to get this into the same cycle as your series. > > int netlink_rcv_skb(struct sk_buff *skb, > > int (*cb)(struct sk_buff *, struct nlmsghdr *, > > @@ -1132,6 +1136,10 @@ static inline int nla_parse_nested(struct nlattr *tb[], int maxtype, > > const struct nla_policy *policy, > > struct netlink_ext_ack *extack) > > { > > + if (!(nla->nla_type & NLA_F_NESTED)) { > > + NL_SET_ERR_MSG_ATTR(extack, nla, "nested attribute expected"); > > Maybe reword that to say "NLA_F_NESTED is missing" or so? The "nested > attribute expected" could result in a lot of headscratching (without > looking at the code) because it looks nested if you do nla_nest_start() > etc. How about "NLA_F_NESTED is missing" and "NLA_F_NESTED not expected"? > > > + return -EINVAL; > > + } > > return __nla_parse(tb, maxtype, nla_data(nla), nla_len(nla), policy, > > NL_VALIDATE_STRICT, extack); > > I'd probably put a blank line there but ymmv. OK > > } > > diff --git a/lib/nlattr.c b/lib/nlattr.c > > index adc919b32bf9..92da65cb6637 100644 > > --- a/lib/nlattr.c > > +++ b/lib/nlattr.c > > @@ -184,6 +184,21 @@ static int validate_nla(const struct nlattr *nla, int maxtype, > > } > > } > > > > + if (validate & NL_VALIDATE_NESTED) { > > + if ((pt->type == NLA_NESTED || pt->type == NLA_NESTED_ARRAY) && > > + !(nla->nla_type & NLA_F_NESTED)) { > > + NL_SET_ERR_MSG_ATTR(extack, nla, > > + "nested attribute expected"); > > + return -EINVAL; > > + } > > + if (pt->type != NLA_NESTED && pt->type != NLA_NESTED_ARRAY && > > + pt->type != NLA_UNSPEC && (nla->nla_type & NLA_F_NESTED)) { > > + NL_SET_ERR_MSG_ATTR(extack, nla, > > + "nested attribute not expected"); > > + return -EINVAL; > > Same comment here wrt. the messages, I think they should more explicitly > refer to the flag. > > johannes > > (PS: if you CC me on this address I generally can respond quicker) I'll try to keep that in mind. Michal