linux-kernel - Re: [PATCH] netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Jun 2023 13:55:22 +0000
From:   Gavrilov Ilia <Ilia.Gavrilov@...otecs.ru>
To:     Simon Horman <simon.horman@...igine.com>
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 5/2/23 18:38, Simon Horman wrote:
> 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@...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
>>
>> 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@...igine.com>
> 

Hi, Simon.
I'm sorry to bother you.
Will this patch be applied or rejected?

Вest regards, Ilya.