Re: [PATCH] netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical_param() return value.

[Simon Horman]

On Tue, May 02, 2023 at 02:16:09PM +0000, Gavrilov Ilia wrote:
> On 5/2/23 17:05, Simon Horman wrote:
> > 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@xxxxxxxxxxx>
> >>>
> >>> 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
> 
> Yes, it seems to me that this was originally intended.

Thanks. With my new found understanding, this looks good to me.

Reviewed-by: Simon Horman <simon.horman@xxxxxxxxxxxx>