2018-03-06 19:14:52

by Gustavo A. R. Silva

[permalink] [raw]
Subject: [RFC] netfilter: cttimeout: remove VLA in ctnl_timeout_parse_policy

In preparation to enabling -Wvla, remove VLA and replace it
with dynamic memory allocation.

Signed-off-by: Gustavo A. R. Silva <[email protected]>
---
net/netfilter/nfnetlink_cttimeout.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
index 95b0470..a2f7d92 100644
--- a/net/netfilter/nfnetlink_cttimeout.c
+++ b/net/netfilter/nfnetlink_cttimeout.c
@@ -52,18 +52,26 @@ ctnl_timeout_parse_policy(void *timeouts,
struct net *net, const struct nlattr *attr)
{
int ret = 0;
+ struct nlattr **tb = NULL;

if (likely(l4proto->ctnl_timeout.nlattr_to_obj)) {
- struct nlattr *tb[l4proto->ctnl_timeout.nlattr_max+1];
+ tb = kcalloc(l4proto->ctnl_timeout.nlattr_max + 1, sizeof(*tb),
+ GFP_KERNEL);
+
+ if (!tb)
+ return -ENOMEM;

ret = nla_parse_nested(tb, l4proto->ctnl_timeout.nlattr_max,
attr, l4proto->ctnl_timeout.nla_policy,
NULL);
if (ret < 0)
- return ret;
+ goto err;

ret = l4proto->ctnl_timeout.nlattr_to_obj(tb, net, timeouts);
}
+
+err:
+ kfree(tb);
return ret;
}

--
2.7.4



2018-03-11 22:05:40

by Pablo Neira Ayuso

[permalink] [raw]
Subject: Re: [RFC] netfilter: cttimeout: remove VLA in ctnl_timeout_parse_policy

On Tue, Mar 06, 2018 at 12:47:55PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.

Looks good but...

> Signed-off-by: Gustavo A. R. Silva <[email protected]>
> ---
> net/netfilter/nfnetlink_cttimeout.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
> index 95b0470..a2f7d92 100644
> --- a/net/netfilter/nfnetlink_cttimeout.c
> +++ b/net/netfilter/nfnetlink_cttimeout.c
> @@ -52,18 +52,26 @@ ctnl_timeout_parse_policy(void *timeouts,
> struct net *net, const struct nlattr *attr)
> {
> int ret = 0;
> + struct nlattr **tb = NULL;

I think we don't need to initialize this, right?

>
> if (likely(l4proto->ctnl_timeout.nlattr_to_obj)) {
> - struct nlattr *tb[l4proto->ctnl_timeout.nlattr_max+1];
> + tb = kcalloc(l4proto->ctnl_timeout.nlattr_max + 1, sizeof(*tb),
> + GFP_KERNEL);
> +
> + if (!tb)
> + return -ENOMEM;
>
> ret = nla_parse_nested(tb, l4proto->ctnl_timeout.nlattr_max,
> attr, l4proto->ctnl_timeout.nla_policy,
> NULL);
> if (ret < 0)
> - return ret;
> + goto err;
>
> ret = l4proto->ctnl_timeout.nlattr_to_obj(tb, net, timeouts);
> }
> +
> +err:
> + kfree(tb);
> return ret;
> }
>
> --
> 2.7.4
>

2018-03-11 22:13:24

by Gustavo A. R. Silva

[permalink] [raw]
Subject: Re: [RFC] netfilter: cttimeout: remove VLA in ctnl_timeout_parse_policy

Hi Pablo,

On 03/11/2018 05:04 PM, Pablo Neira Ayuso wrote:
> On Tue, Mar 06, 2018 at 12:47:55PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wvla, remove VLA and replace it
>> with dynamic memory allocation.
>
> Looks good but...
>
>> Signed-off-by: Gustavo A. R. Silva <[email protected]>
>> ---
>> net/netfilter/nfnetlink_cttimeout.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
>> index 95b0470..a2f7d92 100644
>> --- a/net/netfilter/nfnetlink_cttimeout.c
>> +++ b/net/netfilter/nfnetlink_cttimeout.c
>> @@ -52,18 +52,26 @@ ctnl_timeout_parse_policy(void *timeouts,
>> struct net *net, const struct nlattr *attr)
>> {
>> int ret = 0;
>> + struct nlattr **tb = NULL;
>
> I think we don't need to initialize this, right?
>

We actually do have to initialized it because in the unlikely case that
the code block inside the 'if' below is not executed, then we will end
up freeing an uninitialized pointer.

Thanks
--
Gustavo

>>
>> if (likely(l4proto->ctnl_timeout.nlattr_to_obj)) {
>> - struct nlattr *tb[l4proto->ctnl_timeout.nlattr_max+1];
>> + tb = kcalloc(l4proto->ctnl_timeout.nlattr_max + 1, sizeof(*tb),
>> + GFP_KERNEL);
>> +
>> + if (!tb)
>> + return -ENOMEM;
>>
>> ret = nla_parse_nested(tb, l4proto->ctnl_timeout.nlattr_max,
>> attr, l4proto->ctnl_timeout.nla_policy,
>> NULL);
>> if (ret < 0)
>> - return ret;
>> + goto err;
>>
>> ret = l4proto->ctnl_timeout.nlattr_to_obj(tb, net, timeouts);
>> }
>> +
>> +err:
>> + kfree(tb);
>> return ret;
>> }
>>
>> --
>> 2.7.4
>>



2018-03-11 22:22:28

by Pablo Neira Ayuso

[permalink] [raw]
Subject: Re: [RFC] netfilter: cttimeout: remove VLA in ctnl_timeout_parse_policy

On Sun, Mar 11, 2018 at 05:12:09PM -0500, Gustavo A. R. Silva wrote:
> Hi Pablo,
>
> On 03/11/2018 05:04 PM, Pablo Neira Ayuso wrote:
> > On Tue, Mar 06, 2018 at 12:47:55PM -0600, Gustavo A. R. Silva wrote:
> > > In preparation to enabling -Wvla, remove VLA and replace it
> > > with dynamic memory allocation.
> >
> > Looks good but...
> >
> > > Signed-off-by: Gustavo A. R. Silva <[email protected]>
> > > ---
> > > net/netfilter/nfnetlink_cttimeout.c | 12 ++++++++++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
> > > index 95b0470..a2f7d92 100644
> > > --- a/net/netfilter/nfnetlink_cttimeout.c
> > > +++ b/net/netfilter/nfnetlink_cttimeout.c
> > > @@ -52,18 +52,26 @@ ctnl_timeout_parse_policy(void *timeouts,
> > > struct net *net, const struct nlattr *attr)
> > > {
> > > int ret = 0;
> > > + struct nlattr **tb = NULL;
> >
> > I think we don't need to initialize this, right?
> >
>
> We actually do have to initialized it because in the unlikely case that the
> code block inside the 'if' below is not executed, then we will end up
> freeing an uninitialized pointer.

I see, you're right indeed.

We can probably simplify this code, but just doing:

if (!l4proto->ctnl_timeout.nlattr_to_obj))
return 0;

netlink attribute parsing here.

You could even remove the likely() thing, which doesn't make much
sense for control plane code.

I understand this is a larger change, but I think this function will
look better while we're removing VLA.

Would you mind having a look? I'd appreciate if so.

Thanks.

2018-03-11 22:47:08

by Gustavo A. R. Silva

[permalink] [raw]
Subject: Re: [RFC] netfilter: cttimeout: remove VLA in ctnl_timeout_parse_policy



On 03/11/2018 05:21 PM, Pablo Neira Ayuso wrote:
> On Sun, Mar 11, 2018 at 05:12:09PM -0500, Gustavo A. R. Silva wrote:
>> Hi Pablo,
>>
>> On 03/11/2018 05:04 PM, Pablo Neira Ayuso wrote:
>>> On Tue, Mar 06, 2018 at 12:47:55PM -0600, Gustavo A. R. Silva wrote:
>>>> In preparation to enabling -Wvla, remove VLA and replace it
>>>> with dynamic memory allocation.
>>>
>>> Looks good but...
>>>
>>>> Signed-off-by: Gustavo A. R. Silva <[email protected]>
>>>> ---
>>>> net/netfilter/nfnetlink_cttimeout.c | 12 ++++++++++--
>>>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/net/netfilter/nfnetlink_cttimeout.c b/net/netfilter/nfnetlink_cttimeout.c
>>>> index 95b0470..a2f7d92 100644
>>>> --- a/net/netfilter/nfnetlink_cttimeout.c
>>>> +++ b/net/netfilter/nfnetlink_cttimeout.c
>>>> @@ -52,18 +52,26 @@ ctnl_timeout_parse_policy(void *timeouts,
>>>> struct net *net, const struct nlattr *attr)
>>>> {
>>>> int ret = 0;
>>>> + struct nlattr **tb = NULL;
>>>
>>> I think we don't need to initialize this, right?
>>>
>>
>> We actually do have to initialized it because in the unlikely case that the
>> code block inside the 'if' below is not executed, then we will end up
>> freeing an uninitialized pointer.
>
> I see, you're right indeed.
>
> We can probably simplify this code, but just doing:
>
> if (!l4proto->ctnl_timeout.nlattr_to_obj))
> return 0;
>

I wonder if it is better to code this instead:

if (unlikely(!l4proto->ctnl_timeout.nlattr_to_obj)))
return 0;


> netlink attribute parsing here.
>
> You could even remove the likely() thing, which doesn't make much
> sense for control plane code.
>

Why is that?

> I understand this is a larger change, but I think this function will
> look better while we're removing VLA.
>
> Would you mind having a look? I'd appreciate if so.
>

I can do that. No problem.

Thanks
--
Gustavo