[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFEYpNsp/hBEJAGU@corigine.com>
Date: Tue, 2 May 2023 16:05:24 +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 Tue, May 02, 2023 at 11:43:19AM +0000, Gavrilov Ilia wrote:
> On 4/28/23 22:24, Simon Horman wrote:
> > 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,
> >
>
> Hi Simon, thank you for your answer.
>
> > 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;
> > }
> >
>
> ct_sip_parse_numerical_param() returns 0 in to cases 1) when the
> parameter 'expires=' isn't found in the header or 2) it's incorrectly set.
> In the first case, the return value should be ignored, since this is a
> normal situation
> In the second case, it's better to write to the log and return NF_DROP,
> or ignore it too, then checking the return value can be removed as
> unnecessary.
Sorry, I think I misunderstood the intention of your patch earlier.
Do I (now) understand correctly that you are proposing a tristate?
a) return 1 if value is found; *val is set
b) return 0 if value is not found; *val is unchanged
c) return -1 on error; *val is undefined
Powered by blists - more mailing lists