From: Greg KH <gregkh@linuxfoundation.org>
To: Yi Yang <yiyang13@huawei.com>
Cc: jirislaby@kernel.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH v2] tty: vt: selection: fix soft lockup in paste_selection()
Date: Tue, 9 Apr 2024 15:38:21 +0200 [thread overview]
Message-ID: <2024040943-tightwad-handcuff-5eb7@gregkh> (raw)
In-Reply-To: <20240313094529.679957-1-yiyang13@huawei.com>
On Wed, Mar 13, 2024 at 09:45:29AM +0000, Yi Yang wrote:
> Soft lockup occurs when vt device used n_null ldisc, n_null_receivebuf()
> is not implemented in null_ldisc. So tty_ldisc_receive_buf always return
> 0 in paste_selection(), this cause deadloop and cause soft lockup.
Why is a vt using n_null?
What is causing that?
>
> This can be reproduced as follows:
> int ldisc = 0x1b; // 0x1b is n_null
> struct{
> char subcode;
> struct tiocl_selection sel;
> } data;
> date.subcode = TIOCL_SETSEL;
> data.sel.xs = 0;
> data.sel.xe = 1;
> data.sel.ys = 0;
> data.sel.ye = 1;
> data.sel.sel_mode = TIOCL_SELCHAR;
> char bytes[2] = {TIOCL_PASTESEL, 0};
> open("ttyxx", O_RDWR) // open a vt device
> ioctl(fd, TIOCSETD, &ldisc) // set ldisc to n_null
> ioctl(fd, TIOCLINUX, &data.subcode);
> ioctl(fd, TIOCLINUX, bytes); // cause deadloop
>
> Fix soft lockup by check receive_buf() and receive_buf2() is NULL.
As you had permissions to do this, why prevent it?
>
> Signed-off-by: Yi Yang <yiyang13@huawei.com>
> ---
>
> v2:Change Check Condition.
>
> drivers/tty/vt/selection.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
> index 564341f1a74f..715e111376a7 100644
> --- a/drivers/tty/vt/selection.c
> +++ b/drivers/tty/vt/selection.c
> @@ -397,6 +397,12 @@ int paste_selection(struct tty_struct *tty)
> ld = tty_ldisc_ref_wait(tty);
> if (!ld)
> return -EIO; /* ldisc was hung up */
> +
> + /*tty_ldisc_receive_buf() won't do anything and cause deadloop later*/
Comments need to be properly formated.
And I do not understand this comment sorry.
> + if (!ld->ops->receive_buf && !ld->ops->receive_buf2) {
Why check reciev_buf pointers here? What is that causing?
This needs to be documented a lot better please.
thanks,
greg k-h
prev parent reply other threads:[~2024-04-09 13:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-13 9:45 [PATCH v2] tty: vt: selection: fix soft lockup in paste_selection() Yi Yang
2024-04-09 13:38 ` Greg KH [this message]
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=2024040943-tightwad-handcuff-5eb7@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=yiyang13@huawei.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.