linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: 张云海 <zhangyunhai@nsfocus.com>, "Solar Designer" <solar@openwall.com>
Cc: b.zolnierkie@samsung.com,
	Yang Yingliang <yangyingliang@huawei.com>,
	Kyungtae Kim <kt0755@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <greg@kroah.com>,
	"Srivatsa S. Bhat" <srivatsa@csail.mit.edu>,
	Anthony Liguori <aliguori@amazon.com>,
	xiao.zhang@windriver.com,
	DRI devel <dri-devel@lists.freedesktop.org>,
	Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
Date: Thu, 30 Jul 2020 08:46:31 +0200	[thread overview]
Message-ID: <659f8dcf-7802-1ca1-1372-eb7fefd4d8f4@kernel.org> (raw)
In-Reply-To: <b764c575-70be-80dd-6718-e84370a7b2b3@nsfocus.com>

Hi, OTOH, you should have CCed all the (public) lists.

On 30. 07. 20, 4:50, 张云海 wrote:
> Zhang Xiao points out that the check should use > instead of >=,
> otherwise the last line will be skip.
> I agree with that, so I modify the patch.
> Could you please verify that it is still correct and sufficient?

IMO, yes, correct -- I was thinking about this yesterday too. Just an
example: hypothetically, if we had:
size_row = 1
tail = 29
size = 30

data[29] would be the last accessible member. Writing to data + tail (as
"29 + 1 > 30" doesn't hold, so the modified check would pass), i.e.
data[29] is still OK. So yes, > is OK, >= would waste space and would be
actually incorrect.

> BTW, Zhang Xiao also points out that the check after the memcpy can be
> remove.
> I also think that was right, but vgacon_scrollback_cur->tail may keep
> the value vgacon_scrollback_cur->size in some case. That is not a
> problem in vgacon_scrollback_update because of the check before the
> memcpy. However, that may break some other code which assumes that
> vgacon_scrollback_cur->tail won't be vgacon_scrollback_cur->size. I do
> not know if there are such code, and if it is the code actually  should
> check it too. But I still not remove the check in the patch to make sure
> it won't breaks other code.

As I wrote about this yesterday:
===
I am also not sure the test I was pointing out on the top of this
message would be of any use after the change. But maybe leave the code
rest in peace.
===

I would let it as is in this particular code. Especially because
vgacon_scrolldelta takes ->tail into consideration and I was too lazy to
study the code there. But if you are willing to study the code there and
confirm the check is superfluous, feel free to remove it. Perhaps in a
separate patch. I was actually testing with the check removed and didn't
hit any issue (which means, in fact, exactly nothing).

> From ad143ede24ff4e61292cc9c96000100aacd97259 Mon Sep 17 00:00:00 2001
> From: Yunhai Zhang <zhangyunhai@nsfocus.com>
> Date: Tue, 28 Jul 2020 09:58:03 +0800
> Subject: [PATCH] Fix for missing check in vgacon scrollback handling
> 
> vgacon_scrollback_update() always left enbough room in the scrollback

"leaves enough"

> buffer for the next call, but if the console size changed that room
> might not actually be enough, and so we need to re-check.

Also, could you add reasoning why you are adding the check to the loop
and not outside (for instance, use your reasoning with numbers or CSI M
as an example).

Could you add a sample output here, something like I had:
===
    This leads to random crashes or KASAN reports like:
    BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
===

It's then easier to google for when this happens to someone who runs
non-patched kernels.

> This fixes CVE-2020-14331.
> 
> Reported-and-debugged-by: 张云海 <zhangyunhai@nsfocus.com>
> Reported-and-debugged-by: Yang Yingliang <yangyingliang@huawei.com>
> Reported-by: Kyungtae Kim <kt0755@gmail.com>
> Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Greg KH <greg@kroah.com>
> Cc: Solar Designer <solar@openwall.com>
> Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
> Cc: Anthony Liguori <aliguori@amazon.com>
> Cc: Yang Yingliang <yangyingliang@huawei.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Oh, and we should:
Cc: stable@vger.kernel.org

> Signed-off-by: Yunhai Zhang <zhangyunhai@nsfocus.com>
> ---
>  drivers/video/console/vgacon.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index 998b0de1812f..37b5711cd958 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -251,6 +251,10 @@ static void vgacon_scrollback_update(struct vc_data *c, int t, int count)
>  	p = (void *) (c->vc_origin + t * c->vc_size_row);
>  
>  	while (count--) {
> +		if ((vgacon_scrollback_cur->tail + c->vc_size_row) > 
> +		    vgacon_scrollback_cur->size)
> +			vgacon_scrollback_cur->tail = 0;
> +
>  		scr_memcpyw(vgacon_scrollback_cur->data +
>  			    vgacon_scrollback_cur->tail,
>  			    p, c->vc_size_row);

thanks,
-- 
js
suse labs

       reply	other threads:[~2020-07-30  6:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200729130710.GA13262@openwall.com>
     [not found] ` <b764c575-70be-80dd-6718-e84370a7b2b3@nsfocus.com>
2020-07-30  6:46   ` Jiri Slaby [this message]
2020-07-30  7:38     ` [PATCH] vgacon: fix out of bounds write to the scrollback buffer Jiri Slaby
2020-07-30 10:39     ` 张云海
2020-07-31  5:22       ` 张云海
2020-08-03  8:08         ` Jiri Slaby
2020-08-03  8:18           ` Greg KH
2020-08-03  8:45             ` Daniel Vetter
2020-08-03  9:47               ` Greg KH
2020-08-03 11:07                 ` Bartlomiej Zolnierkiewicz
2020-08-04  7:37           ` Greg KH
     [not found] <CGME20200729070257eucas1p1f5841756104301e67907136e45d6e9f5@eucas1p1.samsung.com>
2020-07-29  7:02 ` Jiri Slaby
2020-07-29  7:53   ` 张云海
2020-07-29  8:11     ` Jiri Slaby
2020-07-29  8:19       ` 张云海
2020-07-29 11:20         ` Jiri Slaby
2020-07-29 13:37   ` Bartlomiej Zolnierkiewicz

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=659f8dcf-7802-1ca1-1372-eb7fefd4d8f4@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=aliguori@amazon.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=greg@kroah.com \
    --cc=kt0755@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=solar@openwall.com \
    --cc=srivatsa@csail.mit.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=xiao.zhang@windriver.com \
    --cc=yangyingliang@huawei.com \
    --cc=zhangyunhai@nsfocus.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).