From: Simon Horman <simon.horman@corigine.com>
To: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Florian Westphal <fw@strlen.de>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Patrick McHardy <kaber@trash.net>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"coreteam@netfilter.org" <coreteam@netfilter.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lvc-project@linuxtesting.org" <lvc-project@linuxtesting.org>
Subject: Re: [PATCH] netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical_param() return value.
Date: Fri, 28 Apr 2023 21:24:39 +0200 [thread overview]
Message-ID: <ZEwdd7Xj4fQtCXoe@corigine.com> (raw)
In-Reply-To: <20230426150414.2768070-1-Ilia.Gavrilov@infotecs.ru>
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@infotecs.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
>
next prev parent reply other threads:[~2023-04-28 19:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 15:04 [PATCH] netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical_param() return value Gavrilov Ilia
2023-04-28 19:24 ` Simon Horman [this message]
2023-05-02 11:43 ` Gavrilov Ilia
2023-05-02 14:05 ` Simon Horman
2023-05-02 14:16 ` Gavrilov Ilia
2023-05-02 15:38 ` Simon Horman
2023-06-22 13:55 ` Gavrilov Ilia
2023-06-22 14:43 ` Florian Westphal
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=ZEwdd7Xj4fQtCXoe@corigine.com \
--to=simon.horman@corigine.com \
--cc=Ilia.Gavrilov@infotecs.ru \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kaber@trash.net \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.