Received-SPF: pass (google.com: domain of linux-kernel+bounces-31172-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240119103703.2004155-1-shaozhengchao@huawei.com>
In-Reply-To: <20240119103703.2004155-1-shaozhengchao@huawei.com>
From: Eric Dumazet <edumazet@google.com>
Date: Fri, 19 Jan 2024 14:09:01 +0100
Message-ID: <CANn89iLUW5HQQT=D2qnFho5egVxFur3ao+8akSXtMx6aEux9Sg@mail.gmail.com>
Subject: Re: [PATCH v3] ipc/mqueue: fix potential sleeping issue in mqueue_flush_file
To: Zhengchao Shao <shaozhengchao@huawei.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davem@davemloft.net, 
	dsahern@kernel.org, kuba@kernel.org, pabeni@redhat.com, brauner@kernel.org, 
	jlayton@kernel.org, riel@surriel.com, jack@suse.cz, viro@zeniv.linux.org.uk, 
	hdanton@sina.com, yuehaibing@huawei.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 19, 2024 at 11:27=E2=80=AFAM Zhengchao Shao
<shaozhengchao@huawei.com> wrote:
>
> I analyze the potential sleeping issue of the following processes:
> Thread A                                Thread B
> ...                                     netlink_create  //ref =3D 1
> do_mq_notify                            ...
>   sock =3D netlink_getsockbyfilp          ...     //ref =3D 2
>   info->notify_sock =3D sock;             ...
> ...                                     netlink_sendmsg
> ...                                       skb =3D netlink_alloc_large_skb=
  //skb->head is vmalloced
> ...                                       netlink_unicast
> ...                                         sk =3D netlink_getsockbyporti=
d //ref =3D 3
> ...                                         netlink_sendskb
> ...                                           __netlink_sendskb
> ...                                             skb_queue_tail //put skb =
to sk_receive_queue
> ...                                         sock_put //ref =3D 2
> ...                                     ...
> ...                                     netlink_release
> ...                                       deferred_put_nlk_sk //ref =3D 1
> mqueue_flush_file
>   spin_lock
>   remove_notification
>     netlink_sendskb
>       sock_put  //ref =3D 0
>         sk_free
>           ...
>           __sk_destruct
>             netlink_sock_destruct
>               skb_queue_purge  //get skb from sk_receive_queue
>                 ...
>                 __skb_queue_purge_reason
>                   kfree_skb_reason
>                     __kfree_skb
>                     ...
>                     skb_release_all
>                       skb_release_head_state
>                         netlink_skb_destructor
>                           vfree(skb->head)  //sleeping while holding spin=
lock
>
> In netlink_sendmsg, if the memory pointed to by skb->head is allocated by
> vmalloc, and is put to sk_receive_queue queue, also the skb is not freed.
> When the mqueue executes flush, the sleeping bug will occur. Put sock
> after releasing the spinlock.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

I think netlink started to use vmalloc() from commit c05cdb1b864f
("netlink: allow large data transfers from user-space")

> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
> ---
> v3: Put sock after releasing the spinlock.
> v2: CCed some networking maintainer & netdev list
> ---
>  ipc/mqueue.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index 5eea4dc0509e..4832343b7049 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -664,12 +664,23 @@ static ssize_t mqueue_read_file(struct file *filp, =
char __user *u_data,
>  static int mqueue_flush_file(struct file *filp, fl_owner_t id)
>  {
>         struct mqueue_inode_info *info =3D MQUEUE_I(file_inode(filp));
> +       struct sock *sk =3D NULL;
>
>         spin_lock(&info->lock);
> -       if (task_tgid(current) =3D=3D info->notify_owner)
> -               remove_notification(info);
> +       if (task_tgid(current) =3D=3D info->notify_owner) {
> +               if (info->notify_owner !=3D NULL &&
> +                   info->notify.sigev_notify =3D=3D SIGEV_THREAD) {
> +                       sk =3D info->notify_sock;
> +                       sock_hold(sk);
> +               }
>
> +               remove_notification(info);
> +       }
>         spin_unlock(&info->lock);
> +
> +       if (sk)
> +               sock_put(sk);
> +
>         return 0;
>  }
>


Note that we could instead call vfree_atomic() from netlink_skb_destructor(=
)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4ed8ffd58ff375f3fa9f262e6f3b4d1a1aaf2731..9c962347cf859f16fc76e4d8a2f=
d22cdb3d142d6
100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -374,7 +374,7 @@ static void netlink_skb_destructor(struct sk_buff *skb)
        if (is_vmalloc_addr(skb->head)) {
                if (!skb->cloned ||
                    !atomic_dec_return(&(skb_shinfo(skb)->dataref)))
-                       vfree(skb->head);
+                       vfree_atomic(skb->head);

                skb->head =3D NULL;
        }

These big skbs are quite rare IMO, and we also could attempt
high-order allocations
in netlink_alloc_large_skb(), using kvmalloc() instead of vmalloc()
(next week when net-next opens)