From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Lin Ma <linma@zju.edu.cn>,
jgg@ziepe.ca, markzhang@nvidia.com, michaelgur@nvidia.com,
ohartoov@nvidia.com, chenzhongjin@huawei.com, yuancan@huawei.com,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] RDMA/nldev: Add length check for IFLA_BOND_ARP_IP_TARGET parsing
Date: Tue, 25 Jul 2023 21:39:24 +0300 [thread overview]
Message-ID: <20230725183924.GS11388@unreal> (raw)
In-Reply-To: <20230725101405.4cd51059@kernel.org>
On Tue, Jul 25, 2023 at 10:14:05AM -0700, Jakub Kicinski wrote:
> On Tue, 25 Jul 2023 08:25:57 +0300 Leon Romanovsky wrote:
> > > Yeah I have seen that. Just as Jakub said, empty netlink attributes are valid
> > > (they are viewed as flag). The point is that different attribute has different
> > > length requirement. For this specific code, the RDMA_NLDEV_ATTR_STAT_HWCOUNTERS
> > > attribute is a nested one whose inner attributes should be NLA_U32. But as you
> > > can see in variable nldev_policy, the description does not use nested policy to
> > > enfore that, which results in the bug discussed in my commit message.
> > >
> > > [RDMA_NLDEV_ATTR_STAT_HWCOUNTERS] = { .type = NLA_NESTED },
> > >
> > > The elegant fix could be add the nested policy description to nldev_policy while
> > > this is toublesome as no existing nla_attr has been given to this nested nlattr.
> > > Hence, add the length check is the simplest solution and you can see such nla_len
> > > check code all over the kernel.
> >
> > Right, and this is what bothers me.
> >
> > I would more than happy to change nla_for_each_nested() to be something
> > like nla_for_each_nested_type(...., sizeof(u32)), which will skip empty
> > lines, for code which can't have them.
>
> In general the idea of auto-skipping stuff kernel doesn't recognize
> is a bit old school. Better direction would be extending the policy
> validation to cover use cases for such loops.
I'm all in for any solution which will help for average developer to write
netlink code without mistakes.
Thanks
next prev parent reply other threads:[~2023-07-25 18:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-23 7:45 [PATCH v1] RDMA/nldev: Add length check for IFLA_BOND_ARP_IP_TARGET parsing Lin Ma
2023-07-24 17:47 ` Leon Romanovsky
2023-07-25 0:11 ` Lin Ma
2023-07-25 5:25 ` Leon Romanovsky
2023-07-25 5:34 ` Lin Ma
2023-07-25 17:14 ` Jakub Kicinski
2023-07-25 18:39 ` Leon Romanovsky [this message]
2023-07-31 12:33 ` Lin Ma
2023-08-01 8:15 ` Leon Romanovsky
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=20230725183924.GS11388@unreal \
--to=leon@kernel.org \
--cc=chenzhongjin@huawei.com \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=linma@zju.edu.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=markzhang@nvidia.com \
--cc=michaelgur@nvidia.com \
--cc=ohartoov@nvidia.com \
--cc=yuancan@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox