All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: 张云海 <zhangyunhai@nsfocus.com>, b.zolnierkie@samsung.com
Cc: linux-kernel@vger.kernel.org,
	Yang Yingliang <yangyingliang@huawei.com>,
	Kyungtae Kim <kt0755@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <greg@kroah.com>, Solar Designer <solar@openwall.com>,
	"Srivatsa S. Bhat" <srivatsa@csail.mit.edu>,
	Anthony Liguori <aliguori@amazon.com>,
	Security Officers <security@kernel.org>,
	linux-distros@vs.openwall.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
Date: Wed, 29 Jul 2020 10:11:57 +0200	[thread overview]
Message-ID: <c1f267aa-dfb3-91fa-3111-30c1676f1a91@kernel.org> (raw)
In-Reply-To: <55075898-bf95-1805-3358-b0d1438feaa9@nsfocus.com>

Hi,

On 29. 07. 20, 9:53, 张云海 wrote:
> This patch dosen't fix the issue, the check should be in the loop.
> 
> The change of the VT sze is before vgacon_scrollback_update, not in the
> meantime.
> 
> Let's consider the following situation:
> 	suppose:
> 		vgacon_scrollback_cur->size is 65440
> 		vgacon_scrollback_cur->tail is 64960
> 		c->vc_size_row is 160
> 		count is 5
> 	
> 	Reset c->vc_size_row to 200 by VT_RESIZE, then call
> vgacon_scrollback_update.
> 	
> 	This will pass the check, since (vgacon_scrollback_cur->tail +
> c->vc_size_row)
> 	is 65160 which is less then vgacon_scrollback_cur->size(65440).
> 
> 	However, in the 3rd iteration of the loop, vgacon_scrollback_cur->tail
> is update
> 	to 65360, the memcpy will overflow.

But the loop checks for the overflow:
  if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
        vgacon_scrollback_cur->tail = 0;

So the first 2 iterations would write to the end of the buffer and this
3rd one should have zeroed ->tail.

thanks,
-- 
js
suse labs

WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: 张云海 <zhangyunhai@nsfocus.com>, b.zolnierkie@samsung.com
Cc: Security Officers <security@kernel.org>,
	Kyungtae Kim <kt0755@gmail.com>,
	Anthony Liguori <aliguori@amazon.com>, Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org, linux-distros@vs.openwall.org,
	Solar Designer <solar@openwall.com>,
	Yang Yingliang <yangyingliang@huawei.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
Subject: Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
Date: Wed, 29 Jul 2020 08:11:57 +0000	[thread overview]
Message-ID: <c1f267aa-dfb3-91fa-3111-30c1676f1a91@kernel.org> (raw)
In-Reply-To: <55075898-bf95-1805-3358-b0d1438feaa9@nsfocus.com>

Hi,

On 29. 07. 20, 9:53, 张云海 wrote:
> This patch dosen't fix the issue, the check should be in the loop.
> 
> The change of the VT sze is before vgacon_scrollback_update, not in the
> meantime.
> 
> Let's consider the following situation:
> 	suppose:
> 		vgacon_scrollback_cur->size is 65440
> 		vgacon_scrollback_cur->tail is 64960
> 		c->vc_size_row is 160
> 		count is 5
> 	
> 	Reset c->vc_size_row to 200 by VT_RESIZE, then call
> vgacon_scrollback_update.
> 	
> 	This will pass the check, since (vgacon_scrollback_cur->tail +
> c->vc_size_row)
> 	is 65160 which is less then vgacon_scrollback_cur->size(65440).
> 
> 	However, in the 3rd iteration of the loop, vgacon_scrollback_cur->tail
> is update
> 	to 65360, the memcpy will overflow.

But the loop checks for the overflow:
  if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
        vgacon_scrollback_cur->tail = 0;

So the first 2 iterations would write to the end of the buffer and this
3rd one should have zeroed ->tail.

thanks,
-- 
js
suse labs

WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: 张云海 <zhangyunhai@nsfocus.com>, b.zolnierkie@samsung.com
Cc: Security Officers <security@kernel.org>,
	Kyungtae Kim <kt0755@gmail.com>,
	Anthony Liguori <aliguori@amazon.com>, Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-fbdev@vger.kernel.org, linux-distros@vs.openwall.org,
	Solar Designer <solar@openwall.com>,
	Yang Yingliang <yangyingliang@huawei.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
Subject: Re: [PATCH] vgacon: fix out of bounds write to the scrollback buffer
Date: Wed, 29 Jul 2020 10:11:57 +0200	[thread overview]
Message-ID: <c1f267aa-dfb3-91fa-3111-30c1676f1a91@kernel.org> (raw)
In-Reply-To: <55075898-bf95-1805-3358-b0d1438feaa9@nsfocus.com>

Hi,

On 29. 07. 20, 9:53, 张云海 wrote:
> This patch dosen't fix the issue, the check should be in the loop.
> 
> The change of the VT sze is before vgacon_scrollback_update, not in the
> meantime.
> 
> Let's consider the following situation:
> 	suppose:
> 		vgacon_scrollback_cur->size is 65440
> 		vgacon_scrollback_cur->tail is 64960
> 		c->vc_size_row is 160
> 		count is 5
> 	
> 	Reset c->vc_size_row to 200 by VT_RESIZE, then call
> vgacon_scrollback_update.
> 	
> 	This will pass the check, since (vgacon_scrollback_cur->tail +
> c->vc_size_row)
> 	is 65160 which is less then vgacon_scrollback_cur->size(65440).
> 
> 	However, in the 3rd iteration of the loop, vgacon_scrollback_cur->tail
> is update
> 	to 65360, the memcpy will overflow.

But the loop checks for the overflow:
  if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
        vgacon_scrollback_cur->tail = 0;

So the first 2 iterations would write to the end of the buffer and this
3rd one should have zeroed ->tail.

thanks,
-- 
js
suse labs
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-07-29  8:12 UTC|newest]

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

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=c1f267aa-dfb3-91fa-3111-30c1676f1a91@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-distros@vs.openwall.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=security@kernel.org \
    --cc=solar@openwall.com \
    --cc=srivatsa@csail.mit.edu \
    --cc=torvalds@linux-foundation.org \
    --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 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.