[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZEwdd7Xj4fQtCXoe@corigine.com>
Date: Fri, 28 Apr 2023 21:24:39 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Gavrilov Ilia <Ilia.Gavrilov@...otecs.ru>
Cc: Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Patrick McHardy <kaber@...sh.net>,
"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
"coreteam@...filter.org" <coreteam@...filter.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>
Subject: Re: [PATCH] netfilter: nf_conntrack_sip: fix the
ct_sip_parse_numerical_param() return value.
On Wed, Apr 26, 2023 at 03:04:31PM +0000, Gavrilov Ilia wrote:
> ct_sip_parse_numerical_param() returns only 0 or 1 now.
> But process_register_request() and process_register_response() imply
> checking for a negative value if parsing of a numerical header parameter
> failed. Let's fix it.
>
> Found by InfoTeCS on behalf of Linux Verification Center
> (linuxtesting.org) with SVACE.
>
> Fixes: 0f32a40fc91a ("[NETFILTER]: nf_conntrack_sip: create signalling expectations")
> Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@...otecs.ru>
Hi Gavrilov,
although it is a slightly unusual convention for kernel code,
I believe the intention is that this function returns 0 when
it fails (to parse) and 1 on success. So I think that part is fine.
What seems a bit broken is the way that callers use the return value.
1. The call in process_register_response() looks like this:
ret = ct_sip_parse_numerical_param(...)
if (ret < 0) {
nf_ct_helper_log(skb, ct, "cannot parse expires");
return NF_DROP;
}
But ret can only be 0 or 1, so the error handling is never inoked,
and a failure to parse is ignored. I guess failure doesn't occur in
practice.
I suspect this should be:
ret = ct_sip_parse_numerical_param(...)
if (!ret) {
nf_ct_helper_log(skb, ct, "cannot parse expires");
return NF_DROP;
}
2. The callprocess_register_request() looks like this:
if (ct_sip_parse_numerical_param(...)) {
nf_ct_helper_log(skb, ct, "cannot parse expires");
return NF_DROP;
}
But this seems to treat success as an error and vice versa.
if (!ct_sip_parse_numerical_param(...)) {
nf_ct_helper_log(skb, ct, "cannot parse expires");
return NF_DROP;
}
Or, better:
ret = ct_sip_parse_numerical_param(...);
if (!ret) {
...
}
3. The invocation in nf_nat_sip() looks like this:
if (ct_sip_parse_numerical_param(...) > 0 &&
...)
...
This seems correct to me.
> ---
> net/netfilter/nf_conntrack_sip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
> index 77f5e82d8e3f..d0eac27f6ba0 100644
> --- a/net/netfilter/nf_conntrack_sip.c
> +++ b/net/netfilter/nf_conntrack_sip.c
> @@ -611,7 +611,7 @@ int ct_sip_parse_numerical_param(const struct nf_conn *ct, const char *dptr,
> start += strlen(name);
> *val = simple_strtoul(start, &end, 0);
> if (start == end)
> - return 0;
> + return -1;
> if (matchoff && matchlen) {
> *matchoff = start - dptr;
> *matchlen = end - start;
> --
> 2.30.2
>
Powered by blists - more mailing lists