From: Wen Gu <guwen@linux.alibaba.com>
To: Dmitry Antipov <dmantipov@yandex.ru>,
Wenjia Zhang <wenjia@linux.ibm.com>
Cc: Jan Karcher <jaka@linux.ibm.com>,
linux-s390@vger.kernel.org, netdev@vger.kernel.org,
lvc-project@linuxtesting.org
Subject: Re: [PATCH] [RFC] net: smc: fix fasync leak in smc_release()
Date: Wed, 21 Feb 2024 21:09:01 +0800 [thread overview]
Message-ID: <819353f3-f5f9-4a15-96a1-4f3a7fd6b33e@linux.alibaba.com> (raw)
In-Reply-To: <20240221051608.43241-1-dmantipov@yandex.ru>
On 2024/2/21 13:16, Dmitry Antipov wrote:
> I've tracked https://syzkaller.appspot.com/bug?extid=5f1acda7e06a2298fae6
> down to the problem which may be illustrated by the following pseudocode:
>
> int sock;
>
> /* thread 1 */
>
> while (1) {
> struct msghdr msg = { ... };
> sock = socket(AF_SMC, SOCK_STREAM, 0);
> sendmsg(sock, &msg, MSG_FASTOPEN);
> close(sock);
> }
>
> /* thread 2 */
>
> while (1) {
> int on = 1;
> ioctl(sock, FIOASYNC, &on);
> on = 0;
> ioctl(sock, FIOASYNC, &on);
> }
>
> That is, something in thread 1 may cause 'smc_switch_to_fallback()' and
> swap kernel sockets (of 'struct smc_sock') behind 'sock' between 'ioctl()'
> calls in thread 2, so this becomes an attempt to add fasync entry to one
> socket but remove from another one. When 'sock' is closing, '__fput()'
> calls 'f_op->fasync()' _before_ 'f_op->release()', and it's too late to
> revert the trick performed by 'smc_switch_to_fallback()' in 'smc_release()'
> and below. Finally we end up with leaked 'struct fasync_struct' object
> linked to the base socket, and this object is noticed by '__sock_release()'
> ("fasync list not empty"). Of course using 'fasync_remove_entry()' in such
> a way is extremely ugly, but what else we can do without touching generic
> socket code, '__fput()', etc.? Comments are highly appreciated.
>
Hi, Dmitry. Just to confirm if I understand correctly:
1. on = 1; ioctl(sock, FIOASYNC, &on), a fasync entry is added to
smc->sk.sk_socket->wq.fasync_list;
2. Then fallback happend, and swapped the socket:
smc->clcsock->file = smc->sk.sk_socket->file;
smc->clcsock->file->private_data = smc->clcsock;
smc->clcsock->wq.fasync_list = smc->sk.sk_socket->wq.fasync_list;
smc->sk.sk_socket->wq.fasync_list = NULL;
3. on = 0; ioctl(sock, FIOASYNC, &on), the fasync entry is removed
from smc->clcsock->wq.fasync_list,
(Is there a race between 2 and 3 ?)
4. Then close the file, __fput() calls file->f_op->fasync(-1, file, 0),
then sock_fasync() calls fasync_helper(fd, filp, on, &wq->fasync_list)
and fasync_remove_entry() removes entries in smc->clcsock->wq.fasync_list.
Now smc->clcsock->wq.fasync_list is empty.
5. __fput() calls file->f_op->release(inode, file), then sock_close calls
__sock_release, then ops->release calls smc_release(), and __smc_release()
calls smc_restore_fallback_changes() to restore socket:
if (smc->clcsock->file) { /* non-accepted sockets have no file yet */
smc->clcsock->file->private_data = smc->sk.sk_socket;
smc->clcsock->file = NULL;
smc_fback_restore_callbacks(smc);
}
6. Then back to __sock_release, check if sock->wq.fasync_list (that is
smc->sk.sk_socket->wq.fasync_list) is empty and it is empty.
So in which step we leaked the fasync_struct entry in smc->sk.sk_socket->wq.fasync_list?
Looks like I missed something, could you please point it to me?
Thanks!
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> net/smc/af_smc.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 0f53a5c6fd9d..68cde9db5d2f 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -337,9 +337,13 @@ static int smc_release(struct socket *sock)
> else
> lock_sock(sk);
>
> - if (old_state == SMC_INIT && sk->sk_state == SMC_ACTIVE &&
> - !smc->use_fallback)
> + if (smc->use_fallback) {
> + /* FIXME: ugly and should be done in some other way */
> + if (sock->wq.fasync_list)
> + fasync_remove_entry(sock->file, &sock->wq.fasync_list);
> + } else if (old_state == SMC_INIT && sk->sk_state == SMC_ACTIVE) {
> smc_close_active_abort(smc);
> + }
>
> rc = __smc_release(smc);
>
next prev parent reply other threads:[~2024-02-21 13:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-21 5:16 [PATCH] [RFC] net: smc: fix fasync leak in smc_release() Dmitry Antipov
2024-02-21 13:09 ` Wen Gu [this message]
2024-02-21 15:02 ` [lvc-project] " Antipov, Dmitriy
2024-02-23 3:36 ` Wen Gu
2024-03-04 16:35 ` Dmitry Antipov
2024-03-06 14:45 ` Wen Gu
2024-03-06 18:07 ` Dmitry Antipov
2024-03-07 8:58 ` Jan Karcher
2024-03-07 9:57 ` Jan Karcher
2024-03-07 10:21 ` Antipov, Dmitriy
2024-03-26 8:18 ` Antipov, Dmitriy
2024-03-27 6:12 ` Wen Gu
2024-03-07 13:53 ` Wen Gu
2024-03-06 13:44 Dmitry Antipov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=819353f3-f5f9-4a15-96a1-4f3a7fd6b33e@linux.alibaba.com \
--to=guwen@linux.alibaba.com \
--cc=dmantipov@yandex.ru \
--cc=jaka@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=wenjia@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).