All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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.