From: Greg KH <gregkh@linuxfoundation.org>
To: Nguyen Dinh Phi <phind.uet@gmail.com>
Cc: linux-kernel-mentees@lists.linuxfoundation.org,
syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com,
jirislaby@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tty: Fix data race between tiocsti() and flush_to_ldisc()
Date: Fri, 13 Aug 2021 09:33:29 +0200 [thread overview]
Message-ID: <YRYgSZwivcPPMhrS@kroah.com> (raw)
In-Reply-To: <20210807190513.3810821-1-phind.uet@gmail.com>
On Sun, Aug 08, 2021 at 03:05:13AM +0800, Nguyen Dinh Phi wrote:
> The ops->receive_buf() may be accessed concurrently from these two
> functions. If the driver flushes data to the line discipline
> receive_buf() method while tiocsti() is using the ops->receive_buf(),
> the data race will happen.
>
> For example:
> tty_ioctl |tty_ldisc_receive_buf
> ->tioctsi | ->tty_port_default_receive_buf
> | ->tty_ldisc_receive_buf
> ->hci_uart_tty_receive | ->hci_uart_tty_receive
> ->h4_recv | ->h4_recv
>
> In this case, the h4 receive buffer will be overwritten by the
> latecomer, and it cause a memory leak.
That looks to be a bug in the h4 code, if the receive_buf() call can not
be run at the same time, it should have a lock in it, right?
> Hence, change tioctsi() function to use the exclusive lock interface
> from tty_buffer to avoid the data race.
Where is the lock being grabbed from the other receive_buf() call path
to ensure that the lock is always needed here?
>
> Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
> Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
> ---
> drivers/tty/tty_io.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index e8532006e960..746fe13a2054 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -2307,8 +2307,10 @@ static int tiocsti(struct tty_struct *tty, char __user *p)
> ld = tty_ldisc_ref_wait(tty);
> if (!ld)
> return -EIO;
> + tty_buffer_lock_exclusive(tty->port);
> if (ld->ops->receive_buf)
> ld->ops->receive_buf(tty, &ch, &mbz, 1);
> + tty_buffer_unlock_exclusive(tty->port);
Did this fix the syzbot reported issue?
thanks,
greg k-h
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Nguyen Dinh Phi <phind.uet@gmail.com>
Cc: jirislaby@kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
linux-kernel@vger.kernel.org,
syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
Subject: Re: [PATCH] tty: Fix data race between tiocsti() and flush_to_ldisc()
Date: Fri, 13 Aug 2021 09:33:29 +0200 [thread overview]
Message-ID: <YRYgSZwivcPPMhrS@kroah.com> (raw)
In-Reply-To: <20210807190513.3810821-1-phind.uet@gmail.com>
On Sun, Aug 08, 2021 at 03:05:13AM +0800, Nguyen Dinh Phi wrote:
> The ops->receive_buf() may be accessed concurrently from these two
> functions. If the driver flushes data to the line discipline
> receive_buf() method while tiocsti() is using the ops->receive_buf(),
> the data race will happen.
>
> For example:
> tty_ioctl |tty_ldisc_receive_buf
> ->tioctsi | ->tty_port_default_receive_buf
> | ->tty_ldisc_receive_buf
> ->hci_uart_tty_receive | ->hci_uart_tty_receive
> ->h4_recv | ->h4_recv
>
> In this case, the h4 receive buffer will be overwritten by the
> latecomer, and it cause a memory leak.
That looks to be a bug in the h4 code, if the receive_buf() call can not
be run at the same time, it should have a lock in it, right?
> Hence, change tioctsi() function to use the exclusive lock interface
> from tty_buffer to avoid the data race.
Where is the lock being grabbed from the other receive_buf() call path
to ensure that the lock is always needed here?
>
> Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
> Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
> ---
> drivers/tty/tty_io.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index e8532006e960..746fe13a2054 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -2307,8 +2307,10 @@ static int tiocsti(struct tty_struct *tty, char __user *p)
> ld = tty_ldisc_ref_wait(tty);
> if (!ld)
> return -EIO;
> + tty_buffer_lock_exclusive(tty->port);
> if (ld->ops->receive_buf)
> ld->ops->receive_buf(tty, &ch, &mbz, 1);
> + tty_buffer_unlock_exclusive(tty->port);
Did this fix the syzbot reported issue?
thanks,
greg k-h
next prev parent reply other threads:[~2021-08-13 7:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-07 19:05 [PATCH] tty: Fix data race between tiocsti() and flush_to_ldisc() Nguyen Dinh Phi
2021-08-07 19:05 ` Nguyen Dinh Phi
2021-08-13 7:33 ` Greg KH [this message]
2021-08-13 7:33 ` Greg KH
2021-08-13 18:35 ` Phi Nguyen
2021-08-13 18:35 ` Phi Nguyen
2021-08-18 14:03 ` Greg KH
2021-08-18 14:03 ` Greg KH
2021-08-22 16:09 ` Phi Nguyen
2021-08-22 16:09 ` Phi Nguyen
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=YRYgSZwivcPPMhrS@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phind.uet@gmail.com \
--cc=syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.