Re: [PATCH] af_key: Fix send_acquire race with pfkey_register

From: Eric Dumazet
Date: Mon Oct 24 2022 - 01:21:31 EST


On Sun, Oct 23, 2022 at 10:10 PM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> With name space support, it is possible for a pfkey_register to
> occur in the middle of a send_acquire, thus changing the number
> of supported algorithms.
>
> This can be fixed by taking a mutex to make it single-threaded
> again.
>
> Reported-by: syzbot+1e9af9185d8850e2c2fa@xxxxxxxxxxxxxxxxxxxxxxxxx
> Fixes: 283bc9f35bbb ("xfrm: Namespacify xfrm state/policy locks")
> Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
>
> diff --git a/net/key/af_key.c b/net/key/af_key.c
> index c85df5b958d2..4ceef96fef57 100644
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -3160,6 +3160,7 @@ static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct
> (sockaddr_size * 2) +
> sizeof(struct sadb_x_policy);
>
> + mutex_lock(&pfkey_mutex);
> if (x->id.proto == IPPROTO_AH)
> size += count_ah_combs(t);
> else if (x->id.proto == IPPROTO_ESP)
> @@ -3171,8 +3172,10 @@ static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct
> }
>
> skb = alloc_skb(size + 16, GFP_ATOMIC);

Are you sure we can sleep in mutex_lock() ?

Use of GFP_ATOMIC would suggest otherwise :/


> - if (skb == NULL)
> + if (skb == NULL) {
> + mutex_unlock(&pfkey_mutex);
> return -ENOMEM;
> + }
>
> hdr = skb_put(skb, sizeof(struct sadb_msg));
> hdr->sadb_msg_version = PF_KEY_V2;
> @@ -3228,6 +3231,7 @@ static int pfkey_send_acquire(struct xfrm_state *x, struct xfrm_tmpl *t, struct
> dump_ah_combs(skb, t);
> else if (x->id.proto == IPPROTO_ESP)
> dump_esp_combs(skb, t);
> + mutex_unlock(&pfkey_mutex);
>
> /* security context */
> if (xfrm_ctx) {
> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt