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;
MIME-Version: 1.0
References: <000000000000fd9a4005ebbeac67@google.com> <Y1YeSj2vwPvRAW61@gondor.apana.org.au>
In-Reply-To: <Y1YeSj2vwPvRAW61@gondor.apana.org.au>
From:   Eric Dumazet <edumazet@google.com>
Date:   Sun, 23 Oct 2022 22:21:05 -0700
Message-ID: <CANn89i+41Whp=ACQo393s_wPx_MtWAZgL9DqG9aoLomN4ddwTg@mail.gmail.com>
Subject: Re: [PATCH] af_key: Fix send_acquire race with pfkey_register
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     syzbot <syzbot+1e9af9185d8850e2c2fa@syzkaller.appspotmail.com>,
        davem@davemloft.net, kuba@kernel.org, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, pabeni@redhat.com,
        steffen.klassert@secunet.com, syzkaller-bugs@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Oct 23, 2022 at 10:10 PM Herbert Xu <herbert@gondor.apana.org.au> 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@syzkaller.appspotmail.com
> Fixes: 283bc9f35bbb ("xfrm: Namespacify xfrm state/policy locks")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> 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@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt