Hi Yang.
Can you please resend and include Greg in the recipient list.
Greg is maintainer of the console subsystem these days.
Sam
On Mon, Jul 13, 2020 at 11:04:45AM +, Yang Yingliang wrote:
> I got a UAF report in do_update_region() when I doing fuzz test.
>
> [ 51.161905] BUG: K
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> Hi,
>
> On 31. 07. 20, 7:22, 张云海 wrote:
> > 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). g
On 8/3/20 11:47 AM, Greg KH wrote:
> On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote:
>> On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote:
>>>
>>> On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
> Remove whitespace at
On Mon, Aug 03, 2020 at 10:45:07AM +0200, Daniel Vetter wrote:
> On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote:
> >
> > On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> > > Hi,
> > >
> > > On 31. 07. 20, 7:22, 张云海 wrote:
> > > > Remove whitespace at EOL
> > >
> > > I am fine with the
On Mon, Aug 3, 2020 at 10:26 AM Greg KH wrote:
>
> On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> > Hi,
> >
> > On 31. 07. 20, 7:22, 张云海 wrote:
> > > Remove whitespace at EOL
> >
> > I am fine with the patch. However it should be sent properly (inline
> > mail, having a PATCH subjec
On Mon, Aug 03, 2020 at 10:08:43AM +0200, Jiri Slaby wrote:
> Hi,
>
> On 31. 07. 20, 7:22, 张云海 wrote:
> > 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). g
Hi,
On 31. 07. 20, 7:22, 张云海 wrote:
> 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 ques
Remove whitespace at EOL
On 2020/7/30 18:39, 张云海 wrote:
> Update the patch, add CC list, sample output, and Jiri's PoC.
>
> On 2020/7/30 14:46, Jiri Slaby wrote:
>> Hi, OTOH, you should have CCed all the (public) lists.
>
>From ad143ede24ff4e61292cc9c96000100aacd97259 Mon Sep 17 00:00:00 2001
F
Hi,
On 31. 07. 20, 5:23, Yang Yingliang wrote:
> void execute_one(void)
> {
> intptr_t res = 0;
> res = syz_open_dev(0xc, 4, 1);
open(/dev/tty1)
> if (res != -1)
> r[0] = res;
> *(uint16_t*)0x2000 = 0xc;
> *(uint16_t*)0x2002 = 0x373;
> *(uint16_t*)
On 30. 07. 20, 15:24, Yang Yingliang wrote:
>
> On 2020/7/30 19:04, Jiri Slaby wrote:
>> On 13. 07. 20, 12:57, Yang Yingliang wrote:
>>> I got a slab-out-of-bounds report when I doing fuzz test.
>>>
>>> [ 334.989515]
>>> ==
>>> [ 33
On 2020/7/30 19:04, Jiri Slaby wrote:
On 13. 07. 20, 12:57, Yang Yingliang wrote:
I got a slab-out-of-bounds report when I doing fuzz test.
[ 334.989515]
==
[ 334.989577] BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0
On 13. 07. 20, 12:57, Yang Yingliang wrote:
> I got a slab-out-of-bounds report when I doing fuzz test.
>
> [ 334.989515]
> ==
> [ 334.989577] BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
> [ 334.989588] Write of si
Update the patch, add CC list, sample output, and Jiri's PoC.
On 2020/7/30 14:46, Jiri Slaby wrote:
> Hi, OTOH, you should have CCed all the (public) lists.
>From ad143ede24ff4e61292cc9c96000100aacd97259 Mon Sep 17 00:00:00 2001
From: Yunhai Zhang
Date: Tue, 28 Jul 2020 09:58:03 +0800
Subject: [
On 30. 07. 20, 8:46, Jiri Slaby wrote:
> 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
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 suffi
Hi Jiri,
On 7/29/20 9:02 AM, Jiri Slaby wrote:
> The current vgacon's scroll up implementation uses a circural buffer
> in vgacon_scrollback_cur. It always advances tail to prepare it for the
> next write and caps it to zero if the next ->vc_size_row bytes won't fit.
>
> But when we change the
On 29. 07. 20, 10:19, 张云海 wrote:
> On 2020/7/29 16:11, Jiri Slaby wrote:
>> 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
On 2020/7/29 16:11, Jiri Slaby wrote:
> 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 ->ta
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->siz
Hi All,
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_scroll
Hi,
Please re-send adding the correct mailing lists:
* dri-de...@lists.freedesktop.org
* linux-fb...@vger.kernel.org
to Cc: so the patch can be reviewed/merged.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
On 6/4/20 4:38 PM, Yang Yingliang wrot
On Thu, 10 Jan 2019, Nicolas Pitre wrote:
> The vt code is just a frigging mess of integer variables and pointer
> variables referring to the same thing. It is therefore littered with
> casts all over the place. And of course I missed one in this patch.
>
> Here's a revised patch to quiet a w
On Thu, 10 Jan 2019, Nicolas Pitre wrote:
> When CONFIG_VGACON_SOFT_SCROLLBACK is selected, the VGA display memory
> index and vc_visible_origin don't change when scrollback is activated.
> The actual screen content is saved away and the scrollbackdata is copied
> over it. However the vt code, and
On Sat, Mar 10, 2018 at 03:40:59AM -0300, Joao Moreira wrote:
> It is possible to indirectly invoke functions with prototypes that do not
> match those of the respectively used function pointers by using void types.
> Despite widely used as a feature for relaxing function invocation, this
> should
Hi,
On Saturday, March 10, 2018 07:27:21 AM Kees Cook wrote:
> On Fri, Mar 9, 2018 at 10:40 PM, Joao Moreira wrote:
> > It is possible to indirectly invoke functions with prototypes that do not
> > match those of the respectively used function pointers by using void types.
> > Despite widely use
On Fri, Mar 9, 2018 at 10:40 PM, Joao Moreira wrote:
> It is possible to indirectly invoke functions with prototypes that do not
> match those of the respectively used function pointers by using void types.
> Despite widely used as a feature for relaxing function invocation, this
> should be avoid
It would be nice to support more than 512 characters when using a graphical
console. We should be able to support up to 2048 at least.
Dave Airlie wrote:
>On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin wrote:
>> The characters will morph anyway, it is just a matter off having them
>randomly
On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin wrote:
> The characters will morph anyway, it is just a matter off having them
> randomly scream with the intensity bit.
>
> 512-character mode is definitely useful... we get much wider language
> coverage with 512 than with 256, which is why most
The characters will morph anyway, it is just a matter off having them randomly
scream with the intensity bit.
512-character mode is definitely useful... we get much wider language coverage
with 512 than with 256, which is why most distros use a 512 console font.
Dave Airlie wrote:
>On Thu, Ja
On Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin wrote:
> We should clear this bit presumably on switching either from or to 512-char
> mode, since the bit doesn't really make sense either way.
Yeah the only problem going from 512-char is that chars above 256 will
morph into garbage chars below 2
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being reinterpre
On Fri, 17 Nov 2000 [EMAIL PROTECTED] wrote:
>
> Hi James,
>
> here is a patch for vgacon.c could you please check it?
Okay. Thank for for posting it not as a attachment.
> 1) removes explicit 0 initialisation of statics
Those are fine. I already have in the ruby tree for the linux c
> I've checked that and it works both on 2.2 and 2.4 but another test won't
> hurt :-)
No problems here :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
> > 2) removes an apparently unnecesary line in vgacon_scroll:
> > as I see it scr_end is computed anyway after the if statement so
> > no need to put it on the else branch.
>
> Hum. Never noticed that one. I will try this part out just to make sure
> their is no problem.
>
I've checked t
34 matches
Mail list logo
