From: Jiri Slaby <jirislaby@kernel.org>
To: Sven Schnelle <svens@linux.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 1/1] tty: fix out-of-bounds access in tty_driver_lookup_tty()
Date: Fri, 9 Dec 2022 09:43:32 +0100 [thread overview]
Message-ID: <ab7d0789-7e97-5ceb-a5de-110c62f08780@kernel.org> (raw)
In-Reply-To: <yt9dtu25vvyh.fsf@linux.ibm.com>
On 09. 12. 22, 9:10, Sven Schnelle wrote:
> Jiri Slaby <jirislaby@kernel.org> writes:
>
>> On 07. 12. 22, 8:52, Sven Schnelle wrote:
>>> When specifying an invalid console= device like console=tty3270,
>>> tty_driver_lookup_tty() returns the tty struct without checking
>>> whether index is a valid number.
>>> [..]
>>
>> Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
>>
>> Yes, this makes sense as a sanity check for all drivers. But I would
>> _also_ disallow registering such a console in vt:
>> --- a/drivers/tty/vt/vt.c
>> +++ b/drivers/tty/vt/vt.c
>> @@ -3075,6 +3075,11 @@ int vt_kmsg_redirect(int new)
>> * The console must be locked when we get here.
>> */
>>
>> +static int vt_console_setup(struct console *co, char *options)
>> +{
>> + return co->index >= MAX_NR_CONSOLES ? -EINVAL : 0;
>> +}
>> +
>> static void vt_console_print(struct console *co, const char *b,
>> unsigned count)
>> {
>> struct vc_data *vc = vc_cons[fg_console].d;
>> @@ -3158,6 +3163,7 @@ static struct tty_driver
>> *vt_console_device(struct console *c, int *index)
>>
>> static struct console vt_console_driver = {
>> .name = "tty",
>> + .setup = vt_console_setup,
>> .write = vt_console_print,
>> .device = vt_console_device,
>> .unblank = unblank_screen,
>>
>> That means dmesg would say:
>> Console: colour dummy device 80x25
>> printk: console [ttyS0] enabled
>>
>> And not:
>> Console: colour dummy device 80x25
>> printk: console [tty3270] enabled
>> printk: console [ttyS0] enabled
>
> Makes sense. Should i add that to my patch, add a second patch, or
> will you submit that?
If you can create a second patch, it would be great. And if you redo
this one, please trim the stack traces (you can likely even drop the
first one).
thanks,
--
js
suse labs
prev parent reply other threads:[~2022-12-09 8:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 7:52 [PATCH 0/1] crash in tty layer when specifying invalid console=ttyX Sven Schnelle
2022-12-07 7:52 ` [PATCH 1/1] tty: fix out-of-bounds access in tty_driver_lookup_tty() Sven Schnelle
2022-12-09 7:17 ` Jiri Slaby
2022-12-09 8:10 ` Sven Schnelle
2022-12-09 8:43 ` Jiri Slaby [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=ab7d0789-7e97-5ceb-a5de-110c62f08780@kernel.org \
--to=jirislaby@kernel.org \
--cc=borntraeger@de.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=svens@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