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 <redacted>
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: 张云海 [off-list ref]
Reported-and-debugged-by: Yang Yingliang [off-list ref]
Reported-by: Kyungtae Kim <redacted>
Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <redacted>
Cc: Solar Designer <redacted>
Cc: "Srivatsa S. Bhat" <redacted>
Cc: Anthony Liguori <redacted>
Cc: Yang Yingliang <redacted>
Cc: Bartlomiej Zolnierkiewicz <redacted>
Hi, OTOH, you should have CCed all the (public) lists.
On 30. 07. 20, 4:50, 张云海 wrote:
quoted
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.
quoted
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).
quoted
From ad143ede24ff4e61292cc9c96000100aacd97259 Mon Sep 17 00:00:00 2001
From: Yunhai Zhang <redacted>
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"
quoted
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.
quoted
This fixes CVE-2020-14331.
Reported-and-debugged-by: 张云海 [off-list ref]
Reported-and-debugged-by: Yang Yingliang [off-list ref]
Reported-by: Kyungtae Kim <redacted>
Fixes: 15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <redacted>
Cc: Solar Designer <redacted>
Cc: "Srivatsa S. Bhat" <redacted>
Cc: Anthony Liguori <redacted>
Cc: Yang Yingliang <redacted>
Cc: Bartlomiej Zolnierkiewicz <redacted>
@@ -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)>
And git complains here:
.git/rebase-apply/patch:13: trailing whitespace.
if ((vgacon_scrollback_cur->tail + c->vc_size_row) >
warning: 1 line adds whitespace errors.
There is a space at the EOL.
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.
There is also question who is willing to take it?
Bart? Greg? Should we route it via akpm, or will you Linus directly? (I
can sign off and resend the patch which was attached to the mail I am
replying to too, if need be.)
thanks,
--
js
suse labs
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
quoted
Remove whitespace at EOL
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.
There is also question who is willing to take it?
Bart? Greg? Should we route it via akpm, or will you Linus directly? (I
can sign off and resend the patch which was attached to the mail I am
replying to too, if need be.)
I can take it, if Bart can't, just let me know.
thanks,
greg k-h
From: Daniel Vetter <hidden> Date: 2020-08-03 08:45:21
On Mon, Aug 3, 2020 at 10:26 AM Greg KH [off-list ref] wrote:
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
quoted
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
quoted
Remove whitespace at EOL
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.
There is also question who is willing to take it?
Bart? Greg? Should we route it via akpm, or will you Linus directly? (I
can sign off and resend the patch which was attached to the mail I am
replying to too, if need be.)
I can take it, if Bart can't, just let me know.
Yeah vt stuff and console drivers != fbcon go through Greg's tree past
few years ...
Greg, should we maybe add a MAINTAINERS entry that matches on all
things console? With tty/vt you definitely have the other side of that
coin already :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote:
On Mon, Aug 3, 2020 at 10:26 AM Greg KH [off-list ref] wrote:
quoted
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
quoted
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
quoted
Remove whitespace at EOL
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.
There is also question who is willing to take it?
Bart? Greg? Should we route it via akpm, or will you Linus directly? (I
can sign off and resend the patch which was attached to the mail I am
replying to too, if need be.)
I can take it, if Bart can't, just let me know.
Yeah vt stuff and console drivers != fbcon go through Greg's tree past
few years ...
Greg, should we maybe add a MAINTAINERS entry that matches on all
things console? With tty/vt you definitely have the other side of that
coin already :-)
Sure, that would be good as things do fall through the cracks at times.
If you write the patch, I'll merge it :)
greg k-h
On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote:
quoted
On Mon, Aug 3, 2020 at 10:26 AM Greg KH [off-list ref] wrote:
quoted
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
quoted
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
quoted
Remove whitespace at EOL
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.
There is also question who is willing to take it?
Bart? Greg? Should we route it via akpm, or will you Linus directly? (I
can sign off and resend the patch which was attached to the mail I am
replying to too, if need be.)
I can take it, if Bart can't, just let me know.
Yeah vt stuff and console drivers != fbcon go through Greg's tree past
few years ...
Greg, should we maybe add a MAINTAINERS entry that matches on all
things console? With tty/vt you definitely have the other side of that
coin already :-)
Sure, that would be good as things do fall through the cracks at times.
Since taking over fbdev in 2017 I've tried to act as the last resort
Maintainer for console stuff (AFAIK there are no "lost" patches) but
it really deserves its own entry.
Also most console patches make it through you nowadays anyway:
$ git log --pretty=fuller --since 17 drivers/video/console/|grep "Commit\:"|sort|uniq -cd
2 Commit: Arnd Bergmann [off-list ref]
11 Commit: Bartlomiej Zolnierkiewicz [off-list ref]
2 Commit: Daniel Vetter [off-list ref]
3 Commit: Dave Airlie [off-list ref]
12 Commit: Greg Kroah-Hartman [off-list ref]
7 Commit: Linus Torvalds [off-list ref]
2 Commit: Martin Schwidefsky [off-list ref]
If you write the patch, I'll merge it :)
ACK from me. :)
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
quoted
Remove whitespace at EOL
I am fine with the patch. However it should be sent properly (inline
mail, having a PATCH subject etc. -- see
Documentation/process/submitting-patches.rst). git send-email after git
format-patch handles most of it.