From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: syzbot <syzbot+b308f5fd049fbbc6e74f@syzkaller.appspotmail.com>,
b.zolnierkie@samsung.com, daniel.vetter@ffwll.ch, deller@gmx.de,
gregkh@linuxfoundation.org, jirislaby@kernel.org,
syzkaller-bugs@googlegroups.com,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: KASAN: use-after-free Read in bit_putcs
Date: Sun, 27 Sep 2020 00:25:07 +0000 [thread overview]
Message-ID: <47907f77-b14b-b433-45c6-a315193f0c1a@i-love.sakura.ne.jp> (raw)
In-Reply-To: <bbcef674-4ac6-c933-b55d-8961ada97f4c@i-love.sakura.ne.jp>
On 2020/09/27 4:39, Peilin Ye wrote:
> On Sun, Sep 27, 2020 at 01:25:17AM +0900, Tetsuo Handa wrote:
>> Since I don't know the meaning of "struct vt_consize"->v_clin (which is commented
>> with "/* number of pixel rows per character */" but does it mean font size ?),
>> I don't know why we can assign that value to vcp->vc_font.height via
>>
>> if (v.v_clin)
>> vcp->vc_font.height = v.v_clin;
>>
>> in vt_resizex(). While ioctl(PIO_FONT) needs to pass vc->vc_sw->con_font_set()
>> check in con_font_set(), ioctl(VT_RESIZEX) does not pass it in vt_resizex()...
>>
>> Since this problem does not happen if I remove
>>
>> if (v.v_clin)
>> vcp->vc_font.height = v.v_clin;
>
> Hi Tetsuo!
>
>> from vt_resizex(), I guess that some variables are getting confused by change
>> of vc->vc_font.height ...
>
> Yes, see bit_putcs():
>
> (drivers/video/fbdev/core/bitblit.c)
> static void bit_putcs(struct vc_data *vc, struct fb_info *info,
> const unsigned short *s, int count, int yy, int xx,
> int fg, int bg)
> {
> struct fb_image image;
> u32 width = DIV_ROUND_UP(vc->vc_font.width, 8);
> u32 cellsize = width * vc->vc_font.height;
> ^^^^^^^^ ^^^^^^^^^^^^^^
>
> `cellsize` is now too large. Later, in bit_putcs_aligned():
>
> while (cnt--) {
> src = vc->vc_font.data + (scr_readw(s++)&
> charmask)*cellsize;
> ^^^^^^^^
>
> `src` goes out of bounds of the data buffer. At first glance I guess
> this is an out-of-bound read reported as a use-after-free read? The
> crashlog says:
How this OOB access is reported varies.
>
> To resolve this out-of-bound issue for now, I think the easiest way
> is to add a range check in bit_putcs(), or bit_putcs_aligned().
>
> ...but yeah, that `VT_RESIZEX` ioctl looks really buggy, and is already
> causing more issues:
At least, since not all fonts have height = 32 (e.g. font_vga_8x8 is height = 8),
allow changing vc->vc_font.height with only
if (v.v_clin > 32)
return -EINVAL;
validation in VT_RESIZEX looks wrong. This needs more validations.
By the way, can we find a user of VT_RESIZEX? As far as I googled with "VT_RESIZEX",
I couldn't find a userspace program; only explanation of VT_RESIZEX and kernel patches
related to VT_RESIZEX are found. Also, while console_ioctl(4) man page says
Any parameter may be set to zero, indicating "no change"
, the assignment
if (!v.v_vlin)
v.v_vlin = vc->vc_scan_lines;
changes the meaning to
If v_vlin parameter is set to zero, the value for associated console is copied
to each console (instead of preserving current value for that console)
. Maybe for now we can try this (effectively making VT_RESIZEX = VT_RESIZE) ?
vt_ioctl.c | 57 ++++++++++-----------------------------------------------
1 file changed, 10 insertions(+), 47 deletions(-)
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index a4e520bdd521..bc33938e2f20 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -773,58 +773,21 @@ static int vt_resizex(struct vc_data *vc, struct vt_consize __user *cs)
if (copy_from_user(&v, cs, sizeof(struct vt_consize)))
return -EFAULT;
- /* FIXME: Should check the copies properly */
- if (!v.v_vlin)
- v.v_vlin = vc->vc_scan_lines;
-
- if (v.v_clin) {
- int rows = v.v_vlin / v.v_clin;
- if (v.v_rows != rows) {
- if (v.v_rows) /* Parameters don't add up */
- return -EINVAL;
- v.v_rows = rows;
- }
- }
-
- if (v.v_vcol && v.v_ccol) {
- int cols = v.v_vcol / v.v_ccol;
- if (v.v_cols != cols) {
- if (v.v_cols)
- return -EINVAL;
- v.v_cols = cols;
- }
- }
-
- if (v.v_clin > 32)
- return -EINVAL;
+ if (v.v_vlin)
+ pr_info_once("\"struct vt_consize\"->v_vlin is ignored. Please report if you need this.\n");
+ if (v.v_clin)
+ pr_info_once("\"struct vt_consize\"->v_clin is ignored. Please report if you need this.\n");
+ console_lock();
for (i = 0; i < MAX_NR_CONSOLES; i++) {
- struct vc_data *vcp;
+ vc = vc_cons[i].d;
- if (!vc_cons[i].d)
- continue;
- console_lock();
- vcp = vc_cons[i].d;
- if (vcp) {
- int ret;
- int save_scan_lines = vcp->vc_scan_lines;
- int save_font_height = vcp->vc_font.height;
-
- if (v.v_vlin)
- vcp->vc_scan_lines = v.v_vlin;
- if (v.v_clin)
- vcp->vc_font.height = v.v_clin;
- vcp->vc_resize_user = 1;
- ret = vc_resize(vcp, v.v_cols, v.v_rows);
- if (ret) {
- vcp->vc_scan_lines = save_scan_lines;
- vcp->vc_font.height = save_font_height;
- console_unlock();
- return ret;
- }
+ if (vc) {
+ vc->vc_resize_user = 1;
+ vc_resize(vc, v.v_cols, v.v_rows);
}
- console_unlock();
}
+ console_unlock();
return 0;
}
next prev parent reply other threads:[~2020-09-27 0:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-23 17:30 KASAN: use-after-free Read in bit_putcs syzbot
2020-09-26 2:03 ` syzbot
2020-09-26 16:25 ` Tetsuo Handa
2020-09-26 19:39 ` Peilin Ye
2020-09-27 0:25 ` Tetsuo Handa [this message]
2020-09-27 8:28 ` Tetsuo Handa
2020-09-27 9:27 ` Peilin Ye
2020-09-27 11:46 ` [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE Tetsuo Handa
2020-09-27 12:06 ` Greg KH
2020-09-28 17:59 ` Martin Hostettler
2020-09-29 1:12 ` Tetsuo Handa
2020-09-29 10:52 ` Martin Hostettler
2020-09-29 16:56 ` Daniel Vetter
2020-09-29 17:10 ` Greg KH
2021-04-11 21:43 ` Maciej W. Rozycki
2021-04-11 22:15 ` Linus Torvalds
2021-04-12 7:01 ` Daniel Vetter
2021-04-12 13:30 ` Maciej W. Rozycki
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=47907f77-b14b-b433-45c6-a315193f0c1a@i-love.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=b.zolnierkie@samsung.com \
--cc=daniel.vetter@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+b308f5fd049fbbc6e74f@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=torvalds@linux-foundation.org \
/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).