fine but needs lockdep annotation.
turning off the locking correctness validator.
Signed-off-by: Tetsuo Handa
Fixes: 8772c0bb58bbf98a ("drm/vmwgfx: Cleanup pci resource allocation")
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2021/05/02 10:53, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 988d0763361bb65690d60e2bc53a6b72777040c3
> Author: Tetsuo Handa
> Date: Sun Sep 27 11:46:30 2020 +
>
> vt_ioctl: make VT_RESIZEX behave like VT_RESIZE
>
That commit i
On 2021/05/03 22:41, Tetsuo Handa wrote:
> Therefore, I guess that the problem is that fbcon_putcs() from
> do_update_region() from
> redraw_screen() from vt_kdsetmode(KD_TEXT) from ioctl(fd, KDSETMODE, KD_TEXT)
> tries to
> redraw 2 x 16640 despite memory amount allocated for a
_FB_PHYS + VGA_FB_PHYS_LEN) range.
[1] https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
---
drivers/video/fbdev/vga16fb.c | 54 +++
1 file changed, 36 insertions(+), 18 deletions(-)
diff -
On 2021/05/15 5:25, Maciej W. Rozycki wrote:
> NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO
> rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with
> it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is
> kind enough to kno
On 2021/05/15 1:19, Tetsuo Handa wrote:
> Even if it turns out to be safe to always call this
> callback, we will need to involve another callback via "struct fb_ops" for
> checking the upper limits from fbcon_resize(). As a result, we will need
> to modify
>
> dr
On 2020/11/29 19:03, Thomas Zimmermann wrote:
> Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
>> Replacing DPRINTK() statements with pr_debug fixes set but not used
>> warnings. And moves to a more standard logging setup at the same time.
>
> I guess this was added for quick debugging during develop
Hello.
The Linux kernel provides kernel-global WQs (namely, system_wq,
system_highpri_wq,
system_long_wq, system_unbound_wq, system_freezable_wq,
system_power_efficient_wq
and system_freezable_power_efficient_wq). But since attempt to flush
kernel-global
WQs has possibility of deadlock, Tejun H
On 2022/02/24 6:35, Tejun Heo wrote:
> Tetsuo, can you please revert the patch? The patch is incorrect in that it's
> triggering also on work item flushes, not just workqueue flushes.
OK. I removed these patches from my tree.
On 2021/08/30 9:24, Randy Dunlap wrote:
> Note that yres_virtual is set to 0x1000. Is there no practical limit
> (hence limit check) that can be used here?
>
> Also, in vga16fb_check_var(), beginning at line 404:
>
> 404 if (yres > vyres)
> 405 vyres = yres;
> 406
this value be passed to real_y
>> function, the ypos will be out of screen range.This is an out-of-bounds
>> write bug.
>> some driver will check xres and yres in fb_check_var callback,but some not
>> so we add a common check after that callback.
>>
>> Signed-off-by: Hai
On 2021/08/30 22:00, Dan Carpenter wrote:
>>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
>>> index e2757ff1c23d..e483a3f5fd47 100644
>>> --- a/drivers/video/fbdev/vga16fb.c
>>> +++ b/drivers/video/fbdev/vga16fb.c
>>> @@ -403,7 +403,7 @@ static int vga16fb_check_var(s
On 2021/08/30 22:47, Dan Carpenter wrote:
> On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote:
>> On 2021/08/30 22:00, Dan Carpenter wrote:
>>>>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
>>>>> index e2757ff1c23d..
On 2021/08/30 23:30, Geert Uytterhoeven wrote:
> The highest possible value of maxmem inside vga16fb_check_var()
> is 65536.
Yes.
>
> So I believe
>
> if (array_size(vxres, vyres) > maxmem)
>
> should work fine.
My intent is to check at common path than individual module so that we don't
s as needed.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot
Debugged-by: Randy Dunlap
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
---
drivers/video/fbdev/core/fbmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/cor
On 2021/08/31 15:48, Geert Uytterhoeven wrote:
> Furthermore, this restricts the virtual frame buffer size on 64-bit,
> too, while graphics cards can have much more than 4 GiB of RAM.
Excuse me, but do you mean that some hardware allows allocating more than
UINT_MAX bytes of memory for kernel fram
where multiplication
overflow happens, let's reject in the common path.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot
Debugged-by: Randy Dunlap
Signed-off-by: Tetsuo Handa
---
Changes in v2:
Use check_mul_overflow(), suggested by Geert U
where multiplication
overflow happens, let's reject in the common path.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot
Debugged-by: Randy Dunlap
Signed-off-by: Tetsuo Handa
Reviewed-by: Geert Uytterhoeven
---
Changes in v2:
Use check_mul_overflow()
On Wed, Dec 16, 2020 at 5:16 PM Paul E. McKenney wrote:
> In my experience, lockdep will indeed complain if an interrupt handler
> returns while in an RCU read-side critical section.
Can't we add lock status checks into the beginning and the end of interrupt
handler functions
(e.g. whether "stru
On 2021/01/08 0:48, xuhuijie wrote:
> This commit 50145474f6ef(fbcon: remove soft scrollback code) remove soft
> scrollback in
> fbcon. So the shift+PageDown and shift+PageUp is missing. But PageUp is a
> vary important
> feature when system panic or reset. I can get log by PageUp before, but now
This seems to be triggered by "pkg/report: skip printk and other printing
functions " on syzbot side.
The fix should be "kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice."
in linux-next.git.
#syz dup: KASAN: use-after-free Read in string
___
d
On 2019/01/03 18:04, Dmitry Vyukov wrote:
> On Thu, Jan 3, 2019 at 9:55 AM Maarten Lankhorst
> wrote:
>> Just guessing..
>>
>> Does this help?
Yes it will. And while at it, let's fix another one together.
From 291e42211e3cc6d85c915772717dd08d40fb5fed Mon Sep 17 00:
We need to call drm_modeset_acquire_fini() when drm_atomic_state_alloc()
failed or call drm_modeset_acquire_init() after drm_atomic_state_alloc()
succeeded.
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +--
drivers/gpu/drm/drm_mode_object.c | 4
fecycle of crc_work is appropriately managed, fix this problem
by adding INIT_WORK() to vkms_atomic_crtc_reset() side.
[1]
https://syzkaller.appspot.com/bug?id=a5954455fcfa51c29ca2ab55b203076337e1c770
Reported-and-tested-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/gpu/drm/vkms/vkms_crtc.
Commit b30b61ff6b1dc37f in linux-next.git did not get in time for closing
previous report. I assume that a pull request will be sent shortly from
Daniel Vetter.
#syz fix: drm/vkms: Fix flush_work() without INIT_WORK().
___
dri-devel mailing list
dri-dev
(Moving most recipients to bcc: in order to avoid flooding.)
On 2019/03/12 13:08, Al Viro wrote:
> Umm... Might be a good idea to add some plausibility filters - it is,
> in theory, possible that adding a line in a comment changes behaviour
> (without compiler bugs, even - playing with __LINE__ i
syzbot found that a thread can stall for minutes inside
ion_system_heap_allocate() after that thread was killed by SIGKILL [1].
Let's check for SIGKILL before doing memory allocation.
[1]
https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
Signed-off-by: Tetsuo
On 2022/06/02 16:38, Arnd Bergmann wrote:
>> But let's cc the tomoyo and chelsio people.
>
> I think both of them work because the structures are always
> embedded inside of larger structures that have at least word
> alignment. This is the thing I was looking for, and the
> __packed attribute was
Use local wq in order to avoid flush_scheduled_work() usage.
Signed-off-by: Tetsuo Handa
---
Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
using a macro") for background.
This is a blind conversion, and is only compile tested.
.../drm/bridge/cadence/cdn
Use local wq in order to avoid flush_scheduled_work() usage.
Signed-off-by: Tetsuo Handa
---
Changes in v2:
Replace flush_scheduled_work() with flush_workqueue().
Please see commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue()
using a macro") for background.
This is a blind
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() calls. And now
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/gt/selftest_execlists.c
are the last flush_scheduled_work() callers which
On 2022/06/10 23:35, Tetsuo Handa wrote:
> Use local wq in order to avoid flush_scheduled_work() usage.
>
> Signed-off-by: Tetsuo Handa
> ---
> Changes in v2:
> Replace flush_scheduled_work() with flush_workqueue().
>
> Please see commit c4f135d643823a86 ("wo
On 2022/02/09 6:08, Daniel Vetter wrote:
> @@ -714,6 +700,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> struct fb_info *info,
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops)
> err = -ENOMEM;
> +
> + INI
Ping?
On 2022/06/10 23:57, Tetsuo Handa wrote:
> Then, does this flush_scheduled_work() mean to wait all
> schedule_work()/schedule_delayed_work()
> calls inside drivers/gpu/drm/i915/ directory?
Ping?
On 2022/06/13 22:57, Tetsuo Handa wrote:
> Thus, how do we want to handle this race window?
>
> flush_delayed_work(&mhdp->hdcp.check_work) followed by
> flush_work(&mhdp->hdcp.prop_work) (i.e. flush as much as possible) ?
>
> cancel_delayed_work_sync(
On 2022/06/30 16:46, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 10/06/2022 15:57, Tetsuo Handa wrote:
>> Hello.
>>
>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
>> a macro") explains, we are removing flush_scheduled_work(
On 2022/06/30 19:17, Tvrtko Ursulin wrote:
> Could you give more context on reasoning here please? What is the difference
> between using the system_wq and flushing it from a random context? Or concern
> is about flushing from specific contexts?
Excuse me, but I couldn't catch what you want. Thus,
No response since 2022-06-10. Can somebody take this patch?
On 2022/07/28 10:40, Tetsuo Handa wrote:
> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
> We are on the w
is patch chose "do nothing" for mhdp->hdcp.check_work and
mhdp->hdcp.prop_work. That is, I assume that flush_scheduled_work() in
cdns_mhdp_remove() needs to wait for only mhdp->hpd_work work.
Link:
https://lkml.kernel.org/r/943273cb-c2ec-24e3-5edb-64eacc6e2...@i-love.sakura.ne.
A fbcon bug found that allocation size was wrong.
https://groups.google.com/d/msg/syzkaller-bugs/TVGAFDeUKJo/uchTlvbFAQAJ
You can try adding printk() for examining values because you have reproducers.
___
dri-devel mailing list
dri-devel@lists.freedesk
Hello.
syzbot is reporting that memory allocation size at fbcon_set_font() is too small
because font's height is rounded up from 10 to 16 after memory allocation.
--
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c9235a2f42f8..68fe66e435d3 100644
--
On 2019/12/05 19:16, Dmitry Vyukov wrote:
> On Thu, Dec 5, 2019 at 11:13 AM Paolo Bonzini wrote:
>>
>> On 04/12/19 22:41, syzbot wrote:
>>> syzbot has bisected this bug to:
>>>
>>> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
>>> Author: Russell Currey
>>> Date: Mon Feb 8 04:08:20 2016 +
On 2019/12/05 19:22, Paolo Bonzini wrote:
> Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of
> backtrace and I get to share syzkaller's joy every time. :)
>
> This bisect result is bogus, though Tetsuo found the bug anyway.
> Perhaps you can exclude commits that only touch
Hello.
I noticed that a kernel built with vmwgfx driver fails to boot a Linux guest
on Oracle VM VirtualBox 7.0.4 on Windows 11 on DELL Inspiron 14 5420.
I didn't notice this problem when I booted an older kernel on an older version
of Oracle VM VirtualBox on Windows 8.1 on an older PC.
The locat
On 2023/01/29 15:00, Zack Rusin wrote:
> On Sat, 2023-01-28 at 20:44 +0900, Tetsuo Handa wrote:
>> Hello.
>>
>> I noticed that a kernel built with vmwgfx driver fails to boot a Linux guest
>> on Oracle VM VirtualBox 7.0.4 on Windows 11 on DELL Inspiron 14 5420.
>>
On 2022/11/16 22:06, Ville Syrjälä wrote:
> On Wed, Nov 16, 2022 at 12:08:27PM +0200, Jani Nikula wrote:
>> On Sun, 06 Nov 2022, Tetsuo Handa wrote:
>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>>> macro") says, flush_sche
r/20220923142934.29528-1-tvrtko.ursu...@linux.intel.com
[1]
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
drivers/gpu/drm/i915/
On 2023/03/03 19:11, Tetsuo Handa wrote:
> @@ -79,6 +81,7 @@ static int __init i915_init(void)
> {
> int err, i;
>
> + i915_wq = alloc_workqueue("i915", 0, 0);
Oops. I forgot to add
if (!i915_wq)
return -ENOMEM;
here. But I'd
On 2023/03/06 20:05, Jani Nikula wrote:
> On Fri, 03 Mar 2023, Tetsuo Handa wrote:
>> On 2023/03/03 19:11, Tetsuo Handa wrote:
>>> @@ -79,6 +81,7 @@ static int __init i915_init(void)
>>> {
>>> int err, i;
>>>
>>> + i915_wq = allo
t_hotplug+0xbea/0xda0
drm_fbdev_generic_setup+0x65e/0x9d0
vkms_init+0x9f3/0xc76
(...snipped...)
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc4-00356-g8f2975c2bb4c #924
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
--
Signed-off-b
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
We are on the way for removing all flush_scheduled_work() callers from
the kernel, and there are only 4 callers remaining as of linux-20221104.
driver
9abd498 [1]
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
Tested-by: syzbot
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
---
drivers/video/fbdev/core/fbcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/co
On 2022/12/15 18:36, Geert Uytterhoeven wrote:
> The next line is:
>
> scr_memsetw(save, erase, array3_size(logo_lines, new_cols, 2));
>
> So how can this turn out to be uninitialized later below?
>
> scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2));
>
> What am I miss
On 2023/01/04 1:20, Felix Kuehling wrote:
>
> Am 2023-01-03 um 11:05 schrieb Waiman Long:
>> On 1/3/23 10:39, Felix Kuehling wrote:
>>> The regression point doesn't make sense. The kernel config doesn't enable
>>> CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU could have
>>> cause
On 2023/01/05 20:54, Daniel Vetter wrote:
>>> . Plain memset() in arch/x86/include/asm/string_64.h is redirected to
>>> __msan_memset()
>>> but memsetXX() are not redirected to __msan_memsetXX(). That is, memory
>>> initialization
>>> via memsetXX() results in KMSAN's shadow memory being not upda
On 2023/01/05 22:22, Daniel Vetter wrote:
> Oh I was more asking about the fbdev patch. This here sounds a lot more
> something that needs to be discussed with kmsan people, that's definitely
> not my area.
> -Daniel
Commit a6a00d7e8ffd ("fbcon: Use kzalloc() in fbcon_prepare_logo()") was
redundan
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed
On 2023/03/15 19:47, Luca Coelho wrote:
> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
>&g
On 2023/04/14 19:13, Jani Nikula wrote:
> On Fri, 14 Apr 2023, Tetsuo Handa wrote:
>> On 2023/03/15 19:47, Luca Coelho wrote:
>>> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_wo
directory. Jani Nikula wants to use two workqueues in order to avoid
adding new module globals, but I'm not familiar enough to audit and
split into two workqueues.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed-off-by: Tetsuo Handa
Cc: Tvrtko Ursulin
Cc: Jani Nikul
Commit c53e98934f93 ("mm: vmalloc: use rwsem, mutex for vmap_area_lock and
vmap_block->lock")
is broken. We can't take mutex (a sleeping lock) inside RCU read section (an
atomic context).
@@ -2183,7 +2184,7 @@ static void _vm_unmap_aliases(unsigned long start,
unsigned long end, int flush)
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed
ork()
need to wait.
Therefore, for now let's start with blind/mechanical conversion within
the whole drivers/gpu/drm/i915/ directory, based on an assumption that
i915 does not need to wait for work items outside of this directory.
Link: https://lkml.kernel.org/r/87sfeita1p@intel.com
Signed
On 2023/07/25 2:03, Geert Uytterhoeven wrote:
> The syzbot report turned out to be a false possitive, caused by a KMSAN
> problem. Indeed, after allocating the buffer, it is fully initialized
> using scr_memsetw(). Hence there is no point in allocating zeroed
> memory, while this does incur some
Hello.
I'm getting a boot failure (console stops) as of next-20170403~69.
next-20170403~70 and next-20170331 boot normally.
Would you check commit 8a2398eb335c11b1b33b860ff472c53c6b1bcc43("Merge
remote-tracking branch 'drm-misc/for-linux-next'") ?
--
%G[1.584230] ioc0: LSI53C1030 B0
Hello.
I noticed that printing to consoles can stop forever because console drivers
can wait for memory allocation when memory allocation cannot make progress.
I was testing almost OOM situation and reproduced a situation where allocation
requests fall into infinite too_many_isolated() trap in sh
Sergey Senozhatsky wrote:
> On (07/06/17 19:28), Tetsuo Handa wrote:
> > Pressing SysRq-c caused all locks to be released (doesn't it ?), and console
>
> hm, I think what happened is a bit different thing. sysrq-c didn't
> unlock any of the locks. I suspect that ->b
Thomas Hellstrom wrote:
> So to summarize. Yes, the drm callers can be fixed up, but IMO requiring
> vfree() to be non-atomic is IMO not a good idea if avoidable.
I agree.
I don't know about drm code. But I can find AppArmor code doing
kvfree() from dfa_free() from aa_dfa_free_kref() from kref_pu
Andrey Ryabinin wrote:
> It's safe to call vfree() from rcu callback as in any other interrupt context.
> Commits you listed bellow didn't change anything in that respect.
> They made impossible to call vfree() under stuff like
> preempt_disable()/spin_lock()
I still cannot catch. According to te
Thomas Hellstrom wrote:
> Most likely the spin_is_locked() function is not working on non - SMP
> systems (well how could it?). An oversight from my side.
You are right. I found a description in Documentation/scsi/ChangeLog.megaraid .
there are several checks present in the kernel
Hello.
While trying to debug
https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 ,
I noticed that a crash can happen without opening /dev/ttyXX .
For example, while a driver which syzbot is reporting accepts screen with
var.xres = var.yres = 0 (and a crash is not visible until trying to
turning -ENOMEM.
[1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8
Reported-and-tested-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers
On 2020/07/11 15:16, Tetsuo Handa wrote:
> On 2020/07/10 19:56, Greg Kroah-Hartman wrote:
>> Where is the over/underflow happening here when we set a size to be so
>> small? We should bound the size somewhere, and as you show, that's not
>> really working p
On 2020/07/10 19:56, Greg Kroah-Hartman wrote:
> Where is the over/underflow happening here when we set a size to be so
> small? We should bound the size somewhere, and as you show, that's not
> really working properly, right?
It is bit_clear_margins() where integer underflow is happening (429496
ioctl(fd, FBIOPUT_VSCREENINFO, &var);
and somehow hit unexpectedly long bit_clear_margins() loops. I don't know
why syzbot does not hit general protection fault, but it would depend on
environment because in my VMware environment ioctl(FBIOPUT_VSCREENINFO)
returns -EINVAL if var.xres == var
On 2020/07/14 19:27, Tetsuo Handa wrote:
> On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
>> How does this patch relate to:
>>
>> https://marc.info/?l=linux-fbdev&m=159415024816722&w=2
>>
>> ?
>>
>> It seems to address the same
h and vc->vc_rows * vc->vc_font.heigh do not
cause integer overflow.
[1]
https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6
Reported-and-tested-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/core/bitblit.c | 4 ++--
drivers/video/fbdev/core/fbcon_ccw.c |
On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
> How does this patch relate to:
>
> https://marc.info/?l=linux-fbdev&m=159415024816722&w=2
>
> ?
>
> It seems to address the same issue, I've added George and Dan to Cc:.
George Kennedy's patch does not help for my case.
You can try
On 2020/07/15 2:15, George Kennedy wrote:
> Can you try the a.out built from the original Syzkaller modified repro C
> program? It walks 0-7 through xres and yres of the fb_var_screeninfo struct.
I'm not familiar with exploit code. What do you want to explain via this
program?
> struct fb_var
On 2020/07/14 18:13, Gu Jinxiang wrote:
> I've encountered [BUG: unable to handle kernel NULL pointer dereference at]
> which has call stack like your pattern2.
> And before this happended, I got a lot of memory allocation failure warnings.
> And my kernel is 3.10.0-327.62.1.el7.x86_64.
>
> Since
On 2020/07/15 20:17, Tetsuo Handa wrote:
> On 2020/07/15 18:48, Dan Carpenter wrote:
>>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc,
>>> struct fb_info *info,
>>> region.color = color;
>>> region.rop = ROP_COPY;
>>>
On 2020/07/15 18:48, Dan Carpenter wrote:
>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc, struct
>> fb_info *info,
>> region.color = color;
>> region.rop = ROP_COPY;
>>
>> -if (rw && !bottom_only) {
>> +if ((int) rw > 0 && !bottom_only) {
>>
On 2020/07/16 0:12, Dan Carpenter wrote:
> I've complained about integer overflows in fbdev for a long time...
>
> What I'd like to see is something like the following maybe. I don't
> know how to get the vc_data in fbmem.c so it doesn't include your checks
> for negative.
Yes. Like I said "Thus
On 2020/07/16 19:00, Daniel Vetter wrote:
> On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
>> On 2020/07/16 0:12, Dan Carpenter wrote:
>>> I've complained about integer overflows in fbdev for a long time...
>>>
>>> What I'd like to see i
true after returning from resize_screen(), and I assume
that not calling clear_selection() when resize_screen() will return error
is harmless, let's redo the check by moving resize_screen() earlier.
[1]
https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e
Reported-by:
bot
Suggested-by: Daniel Vetter
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
drivers/video/fbdev/core/fbsysfs.c | 4 ++--
drivers/video/fbdev/ps3fb.c| 4 ++--
include/linux/fb.h | 2 --
4 files changed, 6 insertions(+), 12 deletions(-)
d
igin() from
accessing outdated vc members.
[1]
https://syzkaller.appspot.com/bug?id=6649da2081e2ebdc65c0642c214b27fe91099db3
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/
On 2020/07/30 20:16, Daniel Vetter wrote:
> Patch looks good, except ... does this compile? fbcon_update_vcs is
> defined in fbcon.h, and that doesn't seem to be included here ...
> Maybe what we want is an fb_set_var_ioctl in fbmem.c so that the fbcon
> interaction is a bit better hidden (but that
bot
Suggested-by: Daniel Vetter
Signed-off-by: Tetsuo Handa
Reported-by: kernel test robot for missing #include
---
drivers/video/fbdev/core/fbmem.c | 8 ++--
drivers/video/fbdev/core/fbsysfs.c | 4 ++--
drivers/video/fbdev/ps3fb.c| 5 +++--
include/linux/fb.h | 2 --
An unkillable task report
INFO: task syz-executor.2:10292 can't die for more than 143 seconds.
syz-executor.2 R running task26216 10292 7415 0x4006
Call Trace:
preempt_schedule_irq+0xb0/0x150 kernel/sched/core.c:4346
retint_kernel+0x1b/0x2b
RIP: 0010:bitfill_aligned+0x12/0x200 driver
fbcon_scrolldelta() was removed by commit 50145474f6ef4a9c ("fbcon: remove soft
scrollback code").
#syz fix: fbcon: remove soft scrollback code
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dr
Greg, will you pick up this patch?
It seems that finding the real cause of [3] and actually fixing [3] will be
difficult.
Since I can't reproduce [3] locally, I will have to try flood of "#syz test"
requests
for debug printk() patches.
On 2020/09/11 7:57, Tetsuo Handa wro
On 2020/09/16 17:26, Greg KH wrote:
> On Wed, Sep 16, 2020 at 09:01:06AM +0900, Tetsuo Handa wrote:
>> Greg, will you pick up this patch?
>>
>> It seems that finding the real cause of [3] and actually fixing [3] will be
>> difficult.
>> Since I can't rep
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
Well, vt_io_ioctl(PIO_FONT) initializes "struct console_font_op op;" with
op.width = 8;
op.height = 0;
op.charcount = 256;
and calls con_font_set() from con_font_op(). But the "/* Need to guess font
height [compat] */"
chunk in con_font_set() guesses font's height due to being initialized
s://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3
Reported-by: syzbot
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
---
drivers/tty/vt/vt_ioctl.c | 57 +++
1 file changed, 10 insertions(+), 47 deletions(-)
diff --git a/drivers/tty/vt
A simplified reproducer and debug printk() patch shown below reported that
vc_font.height is increased to 9 via ioctl(VT_RESIZEX) after it was once
decreased from 16 to 2 via ioctl(PIO_FONT).
Since vc_resize() with v.v_rows == 0 preserves current vc->vc_rows value,
this reproducer is bypassing
On 2020/09/29 2:59, Martin Hostettler wrote:
> On Sun, Sep 27, 2020 at 08:46:30PM +0900, Tetsuo Handa wrote:
>> VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what
>> comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX.
>&g
Since transl_l[16] is accessed via cdat[y] >> 4, cdat[y] needs to be
evaluated as an "unsigned char" value in order to fit 0...15 range.
Signed-off-by: Tetsuo Handa
---
drivers/video/fbdev/vga16fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
syzbot is reporting OOB read at vga_8planes_imageblit() [1], for
"cdat[y] >> 4" can become a negative value due to "const char *cdat".
[1]
https://syzkaller.appspot.com/bug?id=0d7a0da1557dcd1989e00cb3692b26d4173b4132
Reported-by: syzbot
Signed-off-by: Tetsuo Handa
1 - 100 of 144 matches
Mail list logo
