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;
Date:   Tue, 2 May 2023 16:05:24 +0200
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.
Message-ID: <ZFEYpNsp/hBEJAGU@corigine.com>
References: <20230426150414.2768070-1-Ilia.Gavrilov@infotecs.ru>
 <ZEwdd7Xj4fQtCXoe@corigine.com>
 <d0a92686-acc4-4fd8-0505-60a8394d05d8@infotecs.ru>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d0a92686-acc4-4fd8-0505-60a8394d05d8@infotecs.ru>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?R3WxVsYG63VE6Z3YPK/SUFlro6RiLEZRjf9mWcKaA4lC1XcfvMAQESKiAyC/?=
 =?us-ascii?Q?SSkvzun1t/ooiEwezGpzUmrw9y6HyEJB7pV2aA5wWNsGnLbE7gQXfIN4royL?=
 =?us-ascii?Q?vIx7w0kkbDU6rvtxcbZ2qNWKl8lNv5dBE9cT0ZEUJ62biZzSHSpwDxzVdsYb?=
 =?us-ascii?Q?adFnQ1E0RwrCOSVaYrLNPHc69bu7cTnn18c4bWFdTFVgGrSEhJiERvjnS8uQ?=
 =?us-ascii?Q?kTCRci0HWtUb66sy+7fvDPWoaKyXdbYKX5ruxE0gh6t/Usj0SsJZRUe76PpY?=
 =?us-ascii?Q?UKS23Nn4AzlMGVlvU7NOQc7eTRa1x0OTjo+iMBKysahhiccxSp8kMMckeN2C?=
 =?us-ascii?Q?cPIPeIdkEHiC18Z2yIFYoYo5siN4a2+qcpvzpllzdmUcHdFNp9+xYDUpDXAk?=
 =?us-ascii?Q?qxJBjWG0jnpfBIxwL2brldEtt5y10QXWqcr6CnhD/Lxp3THMgdr3hn3NA/ge?=
 =?us-ascii?Q?pO0kiu6QhALYCqhbnDS6djCldJaTR4ncaU52h996z0ozH700f+7MpRUGnNIt?=
 =?us-ascii?Q?K8VIPgC1QZ4jWGi8kEy8k7Es3XIzxC/k4HruHaCwD7DRgMkgtxtqC8Mqnbkh?=
 =?us-ascii?Q?wBE9CY/6tY9GcWsbAP6RsjHMDTbj5iOP+giLUCg7gR0soZB8Lrxht1Gj2/nT?=
 =?us-ascii?Q?TL+S7cYvCiXIKnNBL28VKlw+uLoxwkP7nJ24VDuMTkLujB2bcTQD48krybCA?=
 =?us-ascii?Q?R/x14EurI2EJBAH5ZDiCGVygIDDrf+OG6SdtLYlDtJ+6tuFeA2KUQFgj0qc/?=
 =?us-ascii?Q?ETJ/fxVz2vfu818yoS2dGlP4d82KJTYSF+h/MTxmMsbOGNlgKnTH0qxllkI2?=
 =?us-ascii?Q?Uz1GxQ5046lPt+3RqEeTUwEZk0FH4sywcwn73YX4Di6vOwKvXBqaY0f9EjMe?=
 =?us-ascii?Q?r+sSCTbORusIgnhZS1N/78iBYcZFI9bAZKKYig4RfYdRNyLFEOvk9lNsIVw9?=
 =?us-ascii?Q?ELxWkcHzXQAihQ1c7XO3H1pi3YpreRnU8fA0bhVfFOKIeY4a4VW53y58WHzp?=
 =?us-ascii?Q?Hna6+Uv7BLm21rfEa+NSD5lp4rkvnUlt2WSRMSGo8XnIjiqSblrwhr8Zj8J4?=
 =?us-ascii?Q?rqgpA1a2jHW0i1q0K/dHp5gQofBzy3ZCHCl1/Oujde+5JBMaLJ5e0enTBb+U?=
 =?us-ascii?Q?28G77s19cu6Lc0oiAS2wKPZNZfdRwhq3yiW3baBl0OjRBXGjQKZnnc0Nvac/?=
 =?us-ascii?Q?z/Gk49/b5xGCAX21o1MnkTAYb8mjgY6s4T+7pSzoOje4MvpyJ6B6teNGlCZt?=
 =?us-ascii?Q?/9cjr8Ilh92ywg3dZ6kN6FDrQ20HFT2P9nGOY18r+Qoufn7fSTVoiS6xKn9E?=
 =?us-ascii?Q?J7PbbgoctiQ1QVOz0XNHeHq7W4qQhEyiNwB/dIit/5zCQ5QB8vxlcmOZPeyi?=
 =?us-ascii?Q?X8+oaKtUtq9K5E6P43f86uKjD4YJsMOxntq51PwBXTKM/eCDogMXddmqqIDI?=
 =?us-ascii?Q?nOV1lGPV+ZHQj59QC+/etf8pC8zp/lxTbTm+XMTi/k05sFFiLcpBhtTdkYes?=
 =?us-ascii?Q?QgzX7ygEYpNL0d2Alj6nhoTQHev40p9Ox962gKslnlMxE7+HXz7MHOOP/zCZ?=
 =?us-ascii?Q?Bpa4PkkOlb5ruqU3aAA5XmNc83qDj+4O/W/U/Lq+bAp08NMEDjdWHh+wwQzC?=
 =?us-ascii?Q?NkGWoSye9TSGZvi8unS3bfaHo5iyTgQTfwMHzY9CwXTVB2dd7gFhEUE+JwJX?=
 =?us-ascii?Q?Ht494g=3D=3D?=
X-OriginatorOrg: corigine.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ca6ffb8b-7884-4ce2-ad99-08db4b165128
X-MS-Exchange-CrossTenant-AuthSource: PH0PR13MB4842.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2023 14:05:42.8191
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: fe128f2c-073b-4c20-818e-7246a585940c
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 4pwBn2k6qOrRCc0MUG9u6Akbl8MHRXGs93WUe/sBVtzqe136bIWznaGPIwVcWPbi0XXTgeZSFSYlWHOHBzNtB1us71ulndTPiw/VJubEDzs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR13MB6301
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,
        T_SCC_BODY_TEXT_LINE 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

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