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
| ||
|
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