netdev - Re: [PATCH] af_key: Fix send_acquire race with pfkey

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 PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 23 Oct 2022 22:21:05 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     syzbot <syzbot+1e9af9185d8850e2c2fa@...kaller.appspotmail.com>,
        davem@...emloft.net, kuba@...nel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, pabeni@...hat.com,
        steffen.klassert@...unet.com, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] af_key: Fix send_acquire race with pfkey_register

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