Message ID | fbb31dc72fb38a69a2aca6c25f1be71d6a8bcc96.1653321424.git.mkubecek@suse.cz (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | [ipsec] Revert "net: af_key: add check for pfkey_broadcast in function pfkey_process" | expand |
On 5/23/22 09:01, Michal Kubecek wrote: > This reverts commit 4dc2a5a8f6754492180741facf2a8787f2c415d7. > > A non-zero return value from pfkey_broadcast() does not necessarily mean > an error occurred as this function returns -ESRCH when no registered > listener received the message. In particular, a call with > BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return > zero so that this commit in fact prevents processing any PF_KEY message. > One visible effect is that racoon daemon fails to find encryption > algorithms like aes and refuses to start. > > Excluding -ESRCH return value would fix this but it's not obvious that > we really want to bail out here and most other callers of > pfkey_broadcast() also ignore the return value. Also, as pointed out by > Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code > should use netlink instead so that we should only disturb the code for > really important fixes. > > Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Maybe you can add a comment above the call such that future tool-based patches submissions to give the author a chance to read the comment above and ask oneself twice whether this is relevant or not?
On Mon, May 23, 2022 at 10:23:22AM -0700, Florian Fainelli wrote: > On 5/23/22 09:01, Michal Kubecek wrote: > > This reverts commit 4dc2a5a8f6754492180741facf2a8787f2c415d7. > > > > A non-zero return value from pfkey_broadcast() does not necessarily mean > > an error occurred as this function returns -ESRCH when no registered > > listener received the message. In particular, a call with > > BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return > > zero so that this commit in fact prevents processing any PF_KEY message. > > One visible effect is that racoon daemon fails to find encryption > > algorithms like aes and refuses to start. > > > > Excluding -ESRCH return value would fix this but it's not obvious that > > we really want to bail out here and most other callers of > > pfkey_broadcast() also ignore the return value. Also, as pointed out by > > Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code > > should use netlink instead so that we should only disturb the code for > > really important fixes. > > > > Signed-off-by: Michal Kubecek <mkubecek@suse.cz> > > Maybe you can add a comment above the call such that future tool-based > patches submissions to give the author a chance to read the comment above > and ask oneself twice whether this is relevant or not? Good point, I'll send a v2 with a warning comment in a moment. Micha
diff --git a/net/key/af_key.c b/net/key/af_key.c index 339d95df19d3..fbb2c16693ad 100644 --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -2826,10 +2826,8 @@ static int pfkey_process(struct sock *sk, struct sk_buff *skb, const struct sadb void *ext_hdrs[SADB_EXT_MAX]; int err; - err = pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, - BROADCAST_PROMISC_ONLY, NULL, sock_net(sk)); - if (err) - return err; + pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL, + BROADCAST_PROMISC_ONLY, NULL, sock_net(sk)); memset(ext_hdrs, 0, sizeof(ext_hdrs)); err = parse_exthdrs(skb, hdr, ext_hdrs);
This reverts commit 4dc2a5a8f6754492180741facf2a8787f2c415d7. A non-zero return value from pfkey_broadcast() does not necessarily mean an error occurred as this function returns -ESRCH when no registered listener received the message. In particular, a call with BROADCAST_PROMISC_ONLY flag and null one_sk argument can never return zero so that this commit in fact prevents processing any PF_KEY message. One visible effect is that racoon daemon fails to find encryption algorithms like aes and refuses to start. Excluding -ESRCH return value would fix this but it's not obvious that we really want to bail out here and most other callers of pfkey_broadcast() also ignore the return value. Also, as pointed out by Steffen Klassert, PF_KEY is kind of deprecated and newer userspace code should use netlink instead so that we should only disturb the code for really important fixes. Signed-off-by: Michal Kubecek <mkubecek@suse.cz> --- net/key/af_key.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)