Message ID | 20230426150414.2768070-1-Ilia.Gavrilov@infotecs.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp324232vqo; Wed, 26 Apr 2023 08:24:20 -0700 (PDT) X-Google-Smtp-Source: AKy350bPbee0YeQHnayjbM4eChvHWrVVujsu0rifkr6BvAKZWGRibqeJ+mydCyHrr6fSQrqsHg9y X-Received: by 2002:a17:903:1250:b0:1a6:cd08:5594 with SMTP id u16-20020a170903125000b001a6cd085594mr24791308plh.69.1682522659825; Wed, 26 Apr 2023 08:24:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682522659; cv=none; d=google.com; s=arc-20160816; b=J4chVGpfSLCu1HZIfFCL2mJUszxYYhFlNYlYejJE1DJ+Aq4HHQ7hNFLKmS90ZJVCQE /ZZYuRY5OFLvSBPvpfmshykPcLhvMGKXGwt0+LBpT4vAcCkDd/gFFx/NrucQtXrawd1N 0ixX/AK/dfIAYhpLIbBPhpj4Z4RKVwFdTPLHmTbK75fpwry3ue+B4gvcN6jVNRKBOC9l dGpkrh0GrAu+6+Kmw5Hl7D3gvSs+m1CpzXMiTTjR97qzsnfkfjywbY53Nb6qxdfoO9nb XWkiDl46butPwmiFP11lS9GigeEhVY6TkFn074YN7DPFsPdgu2LF2oCSBflEicfAm77m jqyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from:dkim-signature:dkim-filter; bh=MedIm+CRBEd4wBFXItt1kJMETQQkrwjcl8xl77kiovM=; b=RLuU86uW3cuDzpqMVgIBYgRsiYvHrB2MeA/d8qFaNDYWWcpMru9Oegzpk03qNiCOqo 228MyXGuGenuG/NMGJNfGHld4snC0AZ71fmJwDzRdc7lxP4f9ngjx3Qf1DAihTTT2HiP zCMK8YlTDtBj6o1zo+14A7pclXtg1JifPMD11tU8wERARgKL+7++MTW/MyB5s2rMlLio izNNpzdDT8pRZ/lGH5kguwjUAJE7uh+3TsjGBD4PAoQzDDrddqbDtYhW5kmtsrPneT3d 3fKfPm4f5wK+/9JOT+CWe3ABLQpjR3nEVItwHKtO5RLENusJBMUVPQ8nihu7AdA6djyn 3WVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infotecs.ru header.s=mx header.b=HPLnLR4t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=infotecs.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q13-20020a17090311cd00b001a6db2bef14si17377774plh.157.2023.04.26.08.24.04; Wed, 26 Apr 2023 08:24:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@infotecs.ru header.s=mx header.b=HPLnLR4t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=infotecs.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241220AbjDZPKZ (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Wed, 26 Apr 2023 11:10:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240792AbjDZPKV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Apr 2023 11:10:21 -0400 Received: from mx0.infotecs.ru (mx0.infotecs.ru [91.244.183.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C1F87ED for <linux-kernel@vger.kernel.org>; Wed, 26 Apr 2023 08:10:18 -0700 (PDT) Received: from mx0.infotecs-nt (localhost [127.0.0.1]) by mx0.infotecs.ru (Postfix) with ESMTP id 7B92A1085789; Wed, 26 Apr 2023 18:04:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx0.infotecs.ru 7B92A1085789 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infotecs.ru; s=mx; t=1682521472; bh=MedIm+CRBEd4wBFXItt1kJMETQQkrwjcl8xl77kiovM=; h=From:To:CC:Subject:Date:From; b=HPLnLR4ts/3Y8SbFjB0Xawyp50TRlwaIt4fceP1t8BbvQc4lgJQTqtFLVJozsO5Ij VKwm55CT0gqEPbRGtPFD/DevevAQJ4l2OrJI+CZFIC0VIPXp4rEzoSX/Z1tj10yAJ9 +cgB2C/GewAMwc9RQ2DAVXqp7dFsFtsLBt6mcWEc= Received: from msk-exch-02.infotecs-nt (msk-exch-02.infotecs-nt [10.0.7.192]) by mx0.infotecs-nt (Postfix) with ESMTP id 754A4305F450; Wed, 26 Apr 2023 18:04:31 +0300 (MSK) From: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> To: Pablo Neira Ayuso <pablo@netfilter.org> CC: 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: [PATCH] netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical_param() return value. Thread-Topic: [PATCH] netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical_param() return value. Thread-Index: AQHZeFBn+k9SKA6Ie0ib54vOLuLARQ== Date: Wed, 26 Apr 2023 15:04:31 +0000 Message-ID: <20230426150414.2768070-1-Ilia.Gavrilov@infotecs.ru> Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.0.10] x-exclaimer-md-config: 208ac3cd-1ed4-4982-a353-bdefac89ac0a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 177015 [Apr 26 2023] X-KLMS-AntiSpam-Version: 5.9.59.0 X-KLMS-AntiSpam-Envelope-From: Ilia.Gavrilov@infotecs.ru X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Auth: dkim=none X-KLMS-AntiSpam-Info: LuaCore: 510 510 bc345371020d3ce827abc4c710f5f0ecf15eaf2e, {Tracking_from_domain_doesnt_match_to}, d41d8cd98f00b204e9800998ecf8427e.com:7.1.1;127.0.0.199:7.1.2;infotecs.ru:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, bases: 2023/04/26 03:46:00 X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2023/04/26 04:45:00 #21166225 X-KLMS-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1764252880094279611?= X-GMAIL-MSGID: =?utf-8?q?1764252880094279611?= |
Series |
netfilter: nf_conntrack_sip: fix the ct_sip_parse_numerical_param() return value.
|
|
Commit Message
Gavrilov Ilia
April 26, 2023, 3:04 p.m. UTC
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>
---
net/netfilter/nf_conntrack_sip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
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 >
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@infotecs.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. > 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) { > ... > } > Here is the same as in process_register_response() ret = ct_sip_parse_numerical_param(...); if (ret < 0) { ... return NF_DROP; } Maybe it's better to remove the check altogether? > > 3. The invocation in nf_nat_sip() looks like this: > > if (ct_sip_parse_numerical_param(...) > 0 && > ...) > ... > > This seems correct to me. I agree, everything seems correct here > >> --- >> 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 >>
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@infotecs.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
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@infotecs.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.
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@infotecs.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@corigine.com>
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@infotecs.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@corigine.com> > Hi, Simon. I'm sorry to bother you. Will this patch be applied or rejected? Đ’est regards, Ilya.
Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> wrote: > Hi, Simon. > I'm sorry to bother you. > Will this patch be applied or rejected? Please resend, keeping Simons Reviewd-by tag. Please update the commit message as per your and Simons conversation, i.e. that the return value is now a tristate, 0 for not found and -1 for 'malformed' and that you checked all callers that they will do the right thing.
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;