Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Mon, 23 May 2022 16:32:59 +0200
From:   Steffen Klassert <steffen.klassert@secunet.com>
To:     Michal Kubecek <mkubecek@suse.cz>
CC:     Jiasheng Jiang <jiasheng@iscas.ac.cn>,
        <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
        <edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
        <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: REGRESSION (?) (Re: [PATCH] net: af_key: add check for
 pfkey_broadcast in function pfkey_process)
Message-ID: <20220523143259.GX680067@gauss3.secunet.de>
References: <20220517094231.414168-1-jiasheng@iscas.ac.cn>
 <20220523022438.ofhehjievu2alj3h@lion.mk-sys.cz>
 <20220523083349.zzgdmoq2bzstxla6@lion.mk-sys.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20220523083349.zzgdmoq2bzstxla6@lion.mk-sys.cz>
Precedence: bulk

On Mon, May 23, 2022 at 10:33:49AM +0200, Michal Kubecek wrote:
> On Mon, May 23, 2022 at 04:24:38AM +0200, Michal Kubecek wrote:
> > After upgrading from 5.18-rc7 to 5.18 final, my racoon daemon refuses to
> > start because it cannot find some algorithms (it says "aes"). I have not
> > finished the debugging completely but this patch, mainline commit
> > 4dc2a5a8f675 ("net: af_key: add check for pfkey_broadcast in function
> > pfkey_process"), seems to be the most promising candidate.
> 
> Tested now, reverting commit 4dc2a5a8f675 ("net: af_key: add check for
> pfkey_broadcast in function pfkey_process") seems to fix the issue,
> after rebuilding the af_key module with this commit reverted and
> reloading it, racoon daemon starts and works and /proc/crypto shows
> algrorithms it did not without the revert.
> 
> We might get away with changing the test to
> 
> 	if (err && err != -ESRCH)
> 		return err;
> 
> but I'm not sure if bailing up on failed notification broadcast is
> really what we want. Also, most other calling sites of pfkey_broadcast()
> do not check the return value either so if we want to add the check, it
> should probably be done more consistently. So for now, a revert is IMHO
> more appropriate.

Yes, let's just revert it. Maybe we should only accept serious security
bugfixes for the pfkey interface and leave everyting else as it is. Noone
really cares for the pfkey code anymore for more than 10 years. People
should switch to the netlink interface.