[PATCH] drm/vkms: fix misuse of WARN_ON
vkms_vblank_simulate() uses WARN_ON for timing-dependent condition
(timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used
to denote kernel bugs. Use pr_warn() instead.
Signed-off-by: Dmitry Vyukov
Reported-by: syzbot+4fc21a003c8332eb0...@syzkaller.appspotmail.com
Cc: Rodrigo Siqueira
Cc: Melissa Wen
Cc: Haneen Mohammed
Cc: Daniel Vetter
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Change-Id: I7f01c288092bc7e472ec63af198f93ce3d8c49f7
---
drivers/gpu/drm/vkms/vkms_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index 0443b7deeaef6..758d8a98d96b3 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -18,7 +18,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct
hrtimer *timer)
ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
output->period_ns);
- WARN_ON(ret_overrun != 1);
+ if (ret_overrun != 1)
+ pr_warn("%s: vblank timer overrun\n", __func__);
spin_lock(&output->lock);
ret = drm_crtc_handle_vblank(crtc);
base-commit: e94c55b8e0a0bbe9a026250cf31e2fa45957d776
--
2.31.0.291.g576ba9dcdaf-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: lock held when returning to user space! (3)
On Wed, Jan 2, 2019 at 11:59 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1424673b40 > kernel config: https://syzkaller.appspot.com/x/.config?x=53a2f2aa0b1f7606 > dashboard link: https://syzkaller.appspot.com/bug?extid=42e36e1ae3de3f22a7ed > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1453eabf40 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14a492bf40 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+42e36e1ae3de3f22a...@syzkaller.appspotmail.com #syz dup: WARNING: lock held when returning to user space in set_property_atomic > RBP: 006cf018 R08: 0001 R09: 0032 > R10: R11: 0246 R12: 0005 > R13: R14: R15: > > > WARNING: lock held when returning to user space! > 4.20.0+ #395 Not tainted > > syz-executor520/8085 is leaving the kernel with locks still held! > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with > syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/c2c4b9057e7788d1%40google.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: lock held when returning to user space in set_property_atomic
On Thu, Jan 3, 2019 at 9:55 AM Maarten Lankhorst
wrote:
>
> Op 30-12-2018 om 07:21 schreef syzbot:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12d0f55340
> > kernel config: https://syzkaller.appspot.com/x/.config?x=53a2f2aa0b1f7606
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6ea337c427f5083ebdf2
> > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=120d906f40
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1024673b40
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+6ea337c427f5083eb...@syzkaller.appspotmail.com
> >
> > RBP: 7ffe369ca7a0 R08: 0001 R09: 004009ce
> > R10: R11: 0246 R12: 0005
> > R13: R14: R15:
> >
> >
> > WARNING: lock held when returning to user space!
> > 4.20.0+ #174 Not tainted
> >
> > syz-executor556/8153 is leaving the kernel with locks still held!
> > 1 lock held by syz-executor556/8153:
> > #0: 5100c85c (crtc_ww_class_acquire){+.+.}, at:
> > set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
>
> Just guessing..
>
> Does this help?
Hi Maarten,
Please either test or ask syzbot to test:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#testing-patches
> -
> diff --git a/drivers/gpu/drm/drm_mode_object.c
> b/drivers/gpu/drm/drm_mode_object.c
> index cd9bc0ce9be0..004191d01772 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -459,11 +459,11 @@ static int set_property_atomic(struct drm_mode_object
> *obj,
> struct drm_modeset_acquire_ctx ctx;
> int ret;
>
> - drm_modeset_acquire_init(&ctx, 0);
> -
> state = drm_atomic_state_alloc(dev);
> if (!state)
> return -ENOMEM;
> +
> + drm_modeset_acquire_init(&ctx, 0);
> state->acquire_ctx = &ctx;
> retry:
> if (prop == state->dev->mode_config.dpms_property) {
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/fea9b565-06e4-fbb5-7e92-efd133a7028c%40linux.intel.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails
On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira
wrote:
>
> On 02/26, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > If drm_gem_handle_create() fails in vkms_gem_create(), then the
> > vkms_gem_object is freed twice: once when the reference is dropped by
> > drm_gem_object_put_unlocked(), and again by the extra calls to
> > drm_gem_object_release() and kfree().
> >
> > Fix it by skipping the second release and free.
> >
> > This bug was originally found in the vgem driver by syzkaller using
> > fault injection, but I noticed it's also present in the vkms driver.
> >
> > Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> > Cc: Rodrigo Siqueira
> > Cc: Haneen Mohammed
> > Cc: Daniel Vetter
> > Cc: Chris Wilson
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Eric Biggers
> > ---
> > drivers/gpu/drm/vkms/vkms_gem.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_gem.c
> > b/drivers/gpu/drm/vkms/vkms_gem.c
> > index 138b0bb325cf9..69048e73377dc 100644
> > --- a/drivers/gpu/drm/vkms/vkms_gem.c
> > +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> > @@ -111,11 +111,8 @@ struct drm_gem_object *vkms_gem_create(struct
> > drm_device *dev,
> >
> > ret = drm_gem_handle_create(file, &obj->gem, handle);
> > drm_gem_object_put_unlocked(&obj->gem);
> > - if (ret) {
> > - drm_gem_object_release(&obj->gem);
> > - kfree(obj);
> > + if (ret)
> > return ERR_PTR(ret);
> > - }
> >
> > return &obj->gem;
> > }
> > --
> > 2.21.0.rc2.261.ga7da99ff1b-goog
> >
>
> Hi,
>
> Thanks for your patch! :)
>
> The patch looks good for me. I also tested it under the IGT tests on my
> local VM and everything was fine.
Hi Rodrigo,
What are IGT tests? How can I run them?
>
> Reviewed-by: Rodrigo Siqueira
>
> --
> Rodrigo Siqueira
> https://siqueira.tech
> Graduate Student
> Department of Computer Science
> University of São Paulo
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/20190227231202.tycdbcqtk5ylwp4k%40smtp.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: fix use-after-free when drm_gem_handle_create() fails
On Tue, Mar 5, 2019 at 12:23 AM Rodrigo Siqueira
wrote:
>
> On 02/28, Dmitry Vyukov wrote:
> > On Thu, Feb 28, 2019 at 12:12 AM Rodrigo Siqueira
> > wrote:
> > >
> > > On 02/26, Eric Biggers wrote:
> > > > From: Eric Biggers
> > > >
> > > > If drm_gem_handle_create() fails in vkms_gem_create(), then the
> > > > vkms_gem_object is freed twice: once when the reference is dropped by
> > > > drm_gem_object_put_unlocked(), and again by the extra calls to
> > > > drm_gem_object_release() and kfree().
> > > >
> > > > Fix it by skipping the second release and free.
> > > >
> > > > This bug was originally found in the vgem driver by syzkaller using
> > > > fault injection, but I noticed it's also present in the vkms driver.
> > > >
> > > > Fixes: 559e50fd34d1 ("drm/vkms: Add dumb operations")
> > > > Cc: Rodrigo Siqueira
> > > > Cc: Haneen Mohammed
> > > > Cc: Daniel Vetter
> > > > Cc: Chris Wilson
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Eric Biggers
> > > > ---
> > > > drivers/gpu/drm/vkms/vkms_gem.c | 5 +
> > > > 1 file changed, 1 insertion(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_gem.c
> > > > b/drivers/gpu/drm/vkms/vkms_gem.c
> > > > index 138b0bb325cf9..69048e73377dc 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_gem.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> > > > @@ -111,11 +111,8 @@ struct drm_gem_object *vkms_gem_create(struct
> > > > drm_device *dev,
> > > >
> > > > ret = drm_gem_handle_create(file, &obj->gem, handle);
> > > > drm_gem_object_put_unlocked(&obj->gem);
> > > > - if (ret) {
> > > > - drm_gem_object_release(&obj->gem);
> > > > - kfree(obj);
> > > > + if (ret)
> > > > return ERR_PTR(ret);
> > > > - }
> > > >
> > > > return &obj->gem;
> > > > }
> > > > --
> > > > 2.21.0.rc2.261.ga7da99ff1b-goog
> > > >
> > >
> > > Hi,
> > >
> > > Thanks for your patch! :)
> > >
> > > The patch looks good for me. I also tested it under the IGT tests on my
> > > local VM and everything was fine.
>
> Hi,
>
> Patch applied to drm-misc-fixes.
>
> > Hi Rodrigo,
> >
> > What are IGT tests? How can I run them?
>
> Hi Dmitry,
>
> IGT is a test suite focused on DRM drivers.
>
> You can clone the project using the link below:
>
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
>
> In the README, you will find the software dependencies. After you
> install all the required package, just use:
>
> mkdir build && meson build && cd build && ninja
Hi Rodrigo,
Thanks for the info, but this did not work for me.
I installed all recommended packages (including libdw-dev), but then got:
igt-gpu-tools$ mkdir -p build && meson build && cd build && ninja
The Meson build system
Version: 0.46.1
Source dir: /src/igt-gpu-tools
Build dir: /src/igt-gpu-tools/build
Build type: native build
Project name: igt-gpu-tools
Native C compiler: ccache cc (gcc 7.3.0 "cc (Debian 7.3.0-5) 7.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Compiler for C supports arguments -Wbad-function-cast: YES
Compiler for C supports arguments -Wdeclaration-after-statement: YES
Compiler for C supports arguments -Wformat=2: YES
Compiler for C supports arguments -Wimplicit-fallthrough=0: YES
Compiler for C supports arguments -Wlogical-op: YES
Compiler for C supports arguments -Wmissing-declarations: YES
Compiler for C supports arguments -Wmissing-format-attribute: YES
Compiler for C supports arguments -Wmissing-noreturn: YES
Compiler for C supports arguments -Wmissing-prototypes: YES
Compiler for C supports arguments -Wnested-externs: YES
Compiler for C supports arguments -Wold-style-definition: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wredundant-decls: YES
Compiler for C supports arguments -Wshadow: YES
Compiler for C supports arguments -Wstrict-prototypes: YES
Compiler for C supports arguments -Wuninitialized: YES
Compiler for C supports arguments -Wunused: YES
Compiler for C supports arguments -Wno-clobbered -Wclobbered: YES
Compiler for C supports arguments -Wno-maybe-uninitialized
-Wmaybe-uninitialized: YES
Compiler for C supports arguments -Wno
Re: WARNING in vkms_vblank_simulate
On Mon, Mar 11, 2019 at 1:28 PM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 09ef09b4ab95dc405ad4171ec2cd8a4ff5227108
> Author: Shayenne Moura
> Date: Wed Feb 6 20:08:13 2019 +
>
> drm/vkms: WARN when hrtimer_forward_now fails
+Shayenne
This should have been included the author email when mailed by the
bot. This should be fixed now, tests added. Sorry for the churn.
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=128448cf20
> start commit: 09ef09b4 drm/vkms: WARN when hrtimer_forward_now fails
> git tree: upstream
> final crash:https://syzkaller.appspot.com/x/report.txt?x=118448cf20
> console output: https://syzkaller.appspot.com/x/log.txt?x=168448cf20
> kernel config: https://syzkaller.appspot.com/x/.config?x=c1e0e0ec44d1e5ff
> dashboard link: https://syzkaller.appspot.com/bug?extid=0871b14ca2e2fb64f6e3
> userspace arch: amd64
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1787db8d20
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fc988320
>
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Fixes: 09ef09b4 ("drm/vkms: WARN when hrtimer_forward_now fails")
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/11f13c0583d0b48c%40google.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: rcu detected stall in sys_sendfile64 (2)
On Tue, Mar 12, 2019 at 5:08 AM Al Viro wrote:
>
> On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb
> > Author: Chris Wilson
> > Date: Thu Feb 8 10:54:48 2018 +
> >
> > drm/i915: Add missing kerneldoc for 'ent' in i915_driver_init_early
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1322028320
> > start commit: 34e07e42 drm/i915: Add missing kerneldoc for 'ent' in i915..
> > git tree: upstream
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=10a2028320
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1722028320
> > kernel config: https://syzkaller.appspot.com/x/.config?x=abc3dc9b7a900258
> > dashboard link: https://syzkaller.appspot.com/bug?extid=1505c80c74256c6118a5
> > userspace arch: amd64
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12c4dc28c0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15df4108c0
> >
> > Reported-by: syzbot+1505c80c74256c611...@syzkaller.appspotmail.com
> > Fixes: 34e07e42 ("drm/i915: Add missing kerneldoc for 'ent' in
> > i915_driver_init_early")
>
> 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__ is all it would
> take), but the odds that it's _not_ a false positive are very low.
Thanks for pointing this out.
I've started collecting all such cases, so that we are able to draw
broader conclusions later:
https://github.com/google/syzkaller/issues/1051
added for this one:
=
A mix of problems: unrelated bug triggered by the same repro
("WARNING: ODEBUG bug in netdev_freemem"); lots of infrastructure
failures ("failed to copy test binary to VM"); also the original
failure seems to be flaky. All this contributed to pointing to a
random commit.
Al Viro points out that the commit only touches comments, so we could
mark the end result as suspicious.
=
The infrastructure problems is definitely something we need to fix
("failed to copy test binary to VM") (currently the machine hangs
periodically with lots of time consumed by dmcrypt, but I don't know
if it's related or not yet).
Re the comment-only changes, I would like to see more cases where it
would help before we start creating new universes for this. We could
parse sources with clang to understand that a change was comment-only,
but I guess kernel is mostly broken with clang throughout history
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in bpf_jit_free
On Tue, Jun 11, 2019 at 10:04 AM Daniel Vetter wrote:
>
> On Sat, Jun 08, 2019 at 04:22:06AM -0700, syzbot wrote:
> > syzbot has found a reproducer for the following crash on:
> >
> > HEAD commit:79c3ba32 Merge tag 'drm-fixes-2019-06-07-1' of git://anong..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1201b971a0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=60564cb52ab29d5b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2ff1e7cb738fd3c41113
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a3bf51a0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=120d19f2a0
>
> Looking at the reproducer I don't see any calls to ioctl which could end
> up anywhere in drm.
> >
> > The bug was bisected to:
> >
> > commit 0fff724a33917ac581b5825375d0b57affedee76
> > Author: Paul Kocialkowski
> > Date: Fri Jan 18 14:51:13 2019 +
> >
> > drm/sun4i: backend: Use explicit fourcc helpers for packed YUV422 check
>
> And most definitely not in drm/sun4i. You can only hit this if you have
> sun4i and run on arm, which per your config isn't the case.
>
> tldr; smells like bisect gone wrong.
> -Daniel
>From the bisection log it looks like the bug is too hard to trigger
for reliable bisection. So it probably classified one bad commit as
good. But it should got quite close to the right one.
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1467550f20
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=1667550f20
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1267550f20
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+2ff1e7cb738fd3c41...@syzkaller.appspotmail.com
> > Fixes: 0fff724a3391 ("drm/sun4i: backend: Use explicit fourcc helpers for
> > packed YUV422 check")
> >
> > WARNING: CPU: 0 PID: 8951 at kernel/bpf/core.c:851 bpf_jit_free+0x157/0x1b0
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 0 PID: 8951 Comm: kworker/0:0 Not tainted 5.2.0-rc3+ #23
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: events bpf_prog_free_deferred
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > panic+0x2cb/0x744 kernel/panic.c:219
> > __warn.cold+0x20/0x4d kernel/panic.c:576
> > report_bug+0x263/0x2b0 lib/bug.c:186
> > fixup_bug arch/x86/kernel/traps.c:179 [inline]
> > fixup_bug arch/x86/kernel/traps.c:174 [inline]
> > do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272
> > do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291
> > invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986
> > RIP: 0010:bpf_jit_free+0x157/0x1b0
> > Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5d 48 b8 00 02 00 00
> > 00 00 ad de 48 39 43 70 0f 84 05 ff ff ff e8 f9 b5 f4 ff <0f> 0b e9 f9 fe ff
> > ff e8 bd 53 2d 00 e9 d9 fe ff ff 48 89 7d e0 e8
> > RSP: 0018:88808886fcb0 EFLAGS: 00010293
> > RAX: 88808cb6c480 RBX: 88809051d280 RCX: 817ae68d
> > RDX: > >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/20190611080431.GP21222%40phenom.ffwll.local.
> For more options, visit https://groups.google.com/d/optout. RSI:
> 817bf0f7 RDI: 88809051d2f0
> > RBP: 88808886fcd0 R08: 114ccaa8 R09: fbfff14ccaa9
> > R10: fbfff14ccaa8 R11: 8a665547 R12: c90001925000
> > R13: 88809051d2e8 R14: 8880a0e43900 R15: 8880ae834840
> > bpf_prog_free_deferred+0x27a/0x350 kernel/bpf/core.c:1984
> > process_one_work+0x989/0x1790 kernel/workqueue.c:2269
> > worker_thread+0x98/0xe40 kernel/workqueue.c:2415
> > kthread+0x354/0x420 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
Re: WARNING in bpf_jit_free
On Tue, Jun 11, 2019 at 11:01 AM Daniel Vetter wrote: > > On Tue, Jun 11, 2019 at 10:51:23AM +0200, Daniel Vetter wrote: > > On Tue, Jun 11, 2019 at 10:33:21AM +0200, Dmitry Vyukov wrote: > > > On Tue, Jun 11, 2019 at 10:04 AM Daniel Vetter wrote: > > > > > > > > On Sat, Jun 08, 2019 at 04:22:06AM -0700, syzbot wrote: > > > > > syzbot has found a reproducer for the following crash on: > > > > > > > > > > HEAD commit:79c3ba32 Merge tag 'drm-fixes-2019-06-07-1' of > > > > > git://anong.. > > > > > git tree: upstream > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1201b971a0 > > > > > kernel config: > > > > > https://syzkaller.appspot.com/x/.config?x=60564cb52ab29d5b > > > > > dashboard link: > > > > > https://syzkaller.appspot.com/bug?extid=2ff1e7cb738fd3c41113 > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > syz repro: > > > > > https://syzkaller.appspot.com/x/repro.syz?x=14a3bf51a0 > > > > > C reproducer: > > > > > https://syzkaller.appspot.com/x/repro.c?x=120d19f2a0 > > > > > > > > Looking at the reproducer I don't see any calls to ioctl which could end > > > > up anywhere in drm. > > > > > > > > > > The bug was bisected to: > > > > > > > > > > commit 0fff724a33917ac581b5825375d0b57affedee76 > > > > > Author: Paul Kocialkowski > > > > > Date: Fri Jan 18 14:51:13 2019 + > > > > > > > > > > drm/sun4i: backend: Use explicit fourcc helpers for packed YUV422 > > > > > check > > > > > > > > And most definitely not in drm/sun4i. You can only hit this if you have > > > > sun4i and run on arm, which per your config isn't the case. > > > > > > > > tldr; smells like bisect gone wrong. > > > > -Daniel > > > > > > From the bisection log it looks like the bug is too hard to trigger > > > for reliable bisection. So it probably classified one bad commit as > > > good. But it should got quite close to the right one. > > > > Well statistically it'll get close, since there's a fair chance that it's > > one of the later bisect results that got mischaracterized. > > > > But you can be equally unlucky, and if it's one of the earliers, then it > > can easily be a few thousand commits of. Looking at the log it's mostly > > bad, with a few good sprinkled in, which could just be reproduction > > failures. So might very well be that the very first "good" result is > > wrong. And that very first "good" decision cuts away a big pile of bpf > > related commits. The next "good" decision then only cuts away a pile of > > drm commits, but at that point you're already off the rails most likely. > > > > I'd say re-test on f90d64483ebd394958841f67f8794ab203b319a7 a few times, > > I'm willing to bet that one is actually bad. > > btw if this theory is right, we have a 1-in-4 chance of a spurious "good" > with your test. If you get 10 repeated "good" then that should be good > enough to make playing the lottery a better endeavor :-) Yes, unfortunately. We could do more tests, but if bug reproduction chances are lower, we still the same lottery. And the more tests we do, the higher chances that we hit and get distracted by unrelated kernel bugs. When syzbot started bisecting bugs, I analyzed 120 bisections for correct/not correct and some classification of root causes: https://groups.google.com/forum/#!msg/syzkaller/sR8aAXaWEF4/tTWYRgvmAwAJ https://docs.google.com/spreadsheets/d/1WdBAN54-csaZpD3LgmTcIMR7NDFuQoOZZqPZ-CUqQgA/edit#gid=348315157 https://docs.google.com/spreadsheets/d/1WdBAN54-csaZpD3LgmTcIMR7NDFuQoOZZqPZ-CUqQgA/edit#gid=0 Hard to trigger bugs are a problem, but unrelated kernel bugs is even bigger problem... > -Daniel > > > > > > Cheers, Daniel > > > > > > > > > > bisection log: > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=1467550f20 > > > > > final crash: > > > > > https://syzkaller.appspot.com/x/report.txt?x=1667550f20 > > > > > console output: > > > > > https://syzkaller.appspot.com/x/log.txt?x=1267550f20 > > > > > > > > > > IMPORTANT: if you fix the bug, please add the follow
Re: kernel panic: stack is corrupted in pointer
On Wed, Jul 17, 2019 at 10:58 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1438cde7 Add linux-next specific files for 20190716
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1398805860
> kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> dashboard link: https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa0
From the repro it looks like the same bpf stack overflow bug. +John
We need to dup them onto some canonical report for this bug, or this
becomes unmanageable.
#syz dup: kernel panic: corrupted stack end in dput
> The bug was bisected to:
>
> commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
> Author: Leo Liu
> Date: Fri Jul 13 15:26:28 2018 +
>
> drm/amdgpu: Make sure IB tests flushed after IP resume
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14a4620060
> final crash:https://syzkaller.appspot.com/x/report.txt?x=16a4620060
> console output: https://syzkaller.appspot.com/x/log.txt?x=12a4620060
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+79f5f028005a77ecb...@syzkaller.appspotmail.com
> Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
> resume")
>
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> pointer+0x702/0x750 lib/vsprintf.c:2187
> Shutting down cpus with NMI
> Kernel Offset: disabled
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: memory leak in dma_buf_ioctl
On Wed, Jul 24, 2019 at 11:48 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:abdfd52a Merge tag 'armsoc-defconfig' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=131441d060 > kernel config: https://syzkaller.appspot.com/x/.config?x=d31de3d88059b7fa > dashboard link: https://syzkaller.appspot.com/bug?extid=b2098bc44728a4efb3e9 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12526e5860 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=161784f060 +drivers/dma-buf/dma-buf.c maintainers > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+b2098bc44728a4efb...@syzkaller.appspotmail.com > > executing program > executing program > executing program > executing program > executing program > BUG: memory leak > unreferenced object 0x888114034680 (size 32): >comm "syz-executor110", pid 6894, jiffies 4294947136 (age 13.580s) >hex dump (first 32 bytes): > 00 64 6d 61 62 75 66 3a 00 00 00 00 00 00 00 00 .dmabuf: > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [] kmemleak_alloc_recursive > /./include/linux/kmemleak.h:43 [inline] > [ ] slab_post_alloc_hook /mm/slab.h:522 [inline] > [ ] slab_alloc /mm/slab.c:3319 [inline] > [ ] __do_kmalloc /mm/slab.c:3653 [inline] > [ ] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670 > [ ] memdup_user+0x26/0xa0 /mm/util.c:165 > [ ] strndup_user+0x62/0x80 /mm/util.c:224 > [ ] dma_buf_set_name /drivers/dma-buf/dma-buf.c:331 > [inline] > [ ] dma_buf_ioctl+0x60/0x1b0 > /drivers/dma-buf/dma-buf.c:391 > [ ] vfs_ioctl /fs/ioctl.c:46 [inline] > [ ] file_ioctl /fs/ioctl.c:509 [inline] > [ ] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696 > [ ] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713 > [ ] __do_sys_ioctl /fs/ioctl.c:720 [inline] > [ ] __se_sys_ioctl /fs/ioctl.c:718 [inline] > [ ] __x64_sys_ioctl+0x1e/0x30 /fs/ioctl.c:718 > [<5a8e86d5>] do_syscall_64+0x76/0x1a0 > /arch/x86/entry/common.c:296 > [<7d83529f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > BUG: memory leak > unreferenced object 0x888113b044a0 (size 32): >comm "syz-executor110", pid 6895, jiffies 4294947728 (age 7.660s) >hex dump (first 32 bytes): > 00 64 6d 61 62 75 66 3a 00 00 00 00 00 00 00 00 .dmabuf: > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >backtrace: > [ ] kmemleak_alloc_recursive > /./include/linux/kmemleak.h:43 [inline] > [ ] slab_post_alloc_hook /mm/slab.h:522 [inline] > [ ] slab_alloc /mm/slab.c:3319 [inline] > [ ] __do_kmalloc /mm/slab.c:3653 [inline] > [ ] __kmalloc_track_caller+0x165/0x300 /mm/slab.c:3670 > [ ] memdup_user+0x26/0xa0 /mm/util.c:165 > [ ] strndup_user+0x62/0x80 /mm/util.c:224 > [ ] dma_buf_set_name /drivers/dma-buf/dma-buf.c:331 > [inline] > [ ] dma_buf_ioctl+0x60/0x1b0 > /drivers/dma-buf/dma-buf.c:391 > [ ] vfs_ioctl /fs/ioctl.c:46 [inline] > [ ] file_ioctl /fs/ioctl.c:509 [inline] > [ ] do_vfs_ioctl+0x62a/0x810 /fs/ioctl.c:696 > [ ] ksys_ioctl+0x86/0xb0 /fs/ioctl.c:713 > [ ] __do_sys_ioctl /fs/ioctl.c:720 [inline] > [ ] __se_sys_ioctl /fs/ioctl.c:718 [inline] > [ ] __x64_sys_ioctl+0x1e/0x30 /fs/ioctl.c:718 > [<5a8e86d5>] do_syscall_64+0x76/0x1a0 > /arch/x86/entry/common.c:296 > [<7d83529f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/b68e04058e6a3421%40goog
Re: kernel panic: stack is corrupted in pointer
On Tue, Jul 23, 2019 at 7:26 PM John Fastabend wrote:
>
> Dmitry Vyukov wrote:
> > On Wed, Jul 17, 2019 at 10:58 AM syzbot
> > wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:1438cde7 Add linux-next specific files for 20190716
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1398805860
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa0
> >
> > From the repro it looks like the same bpf stack overflow bug. +John
> > We need to dup them onto some canonical report for this bug, or this
> > becomes unmanageable.
>
> Fixes in bpf tree should fix this. Hopefully, we will squash this once fixes
> percolate up.
>
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Cool! What is the fix?
We don't need to wait for the fix to percolate up (and then down
too!). syzbot gracefully handles when a patch is not yet present
everywhere (it happens all the time).
Btw, this was due to a stack overflow, right? Or something else?
We are trying to make KASAN configuration detect stack overflows too,
so that it does not cause havoc next time. But it turns out to be
non-trivial and our current attempt seems to fail:
https://groups.google.com/forum/#!topic/kasan-dev/IhYv7QYhLfY
> > #syz dup: kernel panic: corrupted stack end in dput
> >
> > > The bug was bisected to:
> > >
> > > commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
> > > Author: Leo Liu
> > > Date: Fri Jul 13 15:26:28 2018 +
> > >
> > > drm/amdgpu: Make sure IB tests flushed after IP resume
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=14a4620060
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=16a4620060
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=12a4620060
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+79f5f028005a77ecb...@syzkaller.appspotmail.com
> > > Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
> > > resume")
> > >
> > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
> > > pointer+0x702/0x750 lib/vsprintf.c:2187
> > > Shutting down cpus with NMI
> > > Kernel Offset: disabled
> > >
> > >
> > > ---
> > > This bug is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkal...@googlegroups.com.
> > >
> > > syzbot will keep track of this bug report. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > > For information about bisection process see:
> > > https://goo.gl/tpsmEJ#bisection
> > > syzbot can test patches for this bug, for details see:
> > > https://goo.gl/tpsmEJ#testing-patches
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/5d37433a832d_3aba2ae4f6ec05bc3a%40john-XPS-13-9370.notmuch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [syzbot] WARNING in __dma_map_sg_attrs
On Tue, 8 Feb 2022 at 13:26, Daniel Vetter wrote: > > On Sat, Feb 05, 2022 at 12:18:23PM -0800, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit:0457e5153e0e Merge tag 'for-linus' of git://git.kernel.org.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=11b2637c70 > > kernel config: https://syzkaller.appspot.com/x/.config?x=6f043113811433a5 > > dashboard link: https://syzkaller.appspot.com/bug?extid=10e27961f4da37c443b2 > > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils > > for Debian) 2.35.2 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c6554270 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1163f48070 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+10e27961f4da37c44...@syzkaller.appspotmail.com > > Adding Gerd, since this seems to blow up in udmabuf. > > I wonder why syzbot didn't figure this out, since it seems to have > correctly added both dma-api and dma-buf people. Just not the maintainer > for the begin_cpu_udmabuf function in the middle of the backtrace? Hi Daniel, syzbot selects only 1 file to get maintainers. Do you suggest using all files in the stack trace? I think it may lead to too many developers CCed since there can be something like 20 files including something from scheduler, arch, fs, etc. > > [ cut here ] > > WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 > > __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > > Modules linked in: > > CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted > > 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 > > Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 > > b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 > > e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 > > RSP: 0018:c90002a07d68 EFLAGS: 00010293 > > RAX: RBX: RCX: > > RDX: 88807e25e2c0 RSI: 81649e91 RDI: 88801b848408 > > RBP: 88801b848000 R08: 0002 R09: 88801d86c74f > > R10: 81649d72 R11: 0001 R12: 0002 > > R13: 88801d86c680 R14: 0001 R15: > > FS: 56e30300() GS:8880b9d0() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 20cc CR3: 1d74a000 CR4: 003506e0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > > > dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 > > get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 > > begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 > > dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 > > dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 > > vfs_ioctl fs/ioctl.c:51 [inline] > > __do_sys_ioctl fs/ioctl.c:874 [inline] > > __se_sys_ioctl fs/ioctl.c:860 [inline] > > __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7f62fcf530f9 > > Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:7ffe3edab9b8 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: RCX: 7f62fcf530f9 > > RDX: 2200 RSI: 40086200 RDI: 0006 > > RBP: 7f62fcf170e0 R08: R09: > > R10: R11: 0246 R12: 7f62fcf17170 > > R13: R14: R15: > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/YgJhjdAbRHdnCZ4T%40phenom.ffwll.local.
Re: [PATCH v2 14/16] kasan: Remove ksize()-related tests
On Fri, 23 Sept 2022 at 22:28, Kees Cook wrote:
>
> In preparation for no longer unpoisoning in ksize(), remove the behavioral
> self-tests for ksize().
>
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: Andrey Konovalov
> Cc: Dmitry Vyukov
> Cc: Vincenzo Frascino
> Cc: Andrew Morton
> Cc: kasan-...@googlegroups.com
> Cc: linux...@kvack.org
> Signed-off-by: Kees Cook
> ---
> lib/test_kasan.c | 42 --
> mm/kasan/shadow.c | 4 +---
> 2 files changed, 1 insertion(+), 45 deletions(-)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index 58c1b01ccfe2..bdd0ced8f8d7 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -753,46 +753,6 @@ static void kasan_global_oob_left(struct kunit *test)
> KUNIT_EXPECT_KASAN_FAIL(test, *(volatile char *)p);
> }
>
> -/* Check that ksize() makes the whole object accessible. */
> -static void ksize_unpoisons_memory(struct kunit *test)
> -{
> - char *ptr;
> - size_t size = 123, real_size;
> -
> - ptr = kmalloc(size, GFP_KERNEL);
> - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
> - real_size = ksize(ptr);
> -
> - OPTIMIZER_HIDE_VAR(ptr);
> -
> - /* This access shouldn't trigger a KASAN report. */
> - ptr[size] = 'x';
I would rather keep the tests and update to the new behavior. We had
bugs in ksize, we need test coverage.
I assume ptr[size] access must now produce an error even after ksize.
> - /* This one must. */
> - KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[real_size]);
> -
> - kfree(ptr);
> -}
> -
> -/*
> - * Check that a use-after-free is detected by ksize() and via normal accesses
> - * after it.
> - */
> -static void ksize_uaf(struct kunit *test)
> -{
> - char *ptr;
> - int size = 128 - KASAN_GRANULE_SIZE;
> -
> - ptr = kmalloc(size, GFP_KERNEL);
> - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
> - kfree(ptr);
> -
> - OPTIMIZER_HIDE_VAR(ptr);
> - KUNIT_EXPECT_KASAN_FAIL(test, ksize(ptr));
This is still a bug that should be detected, right? Calling ksize on a
freed pointer is a bug.
> - KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[0]);
> - KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[size]);
> -}
> -
> static void kasan_stack_oob(struct kunit *test)
> {
> char stack_array[10];
> @@ -1392,8 +1352,6 @@ static struct kunit_case kasan_kunit_test_cases[] = {
> KUNIT_CASE(kasan_stack_oob),
> KUNIT_CASE(kasan_alloca_oob_left),
> KUNIT_CASE(kasan_alloca_oob_right),
> - KUNIT_CASE(ksize_unpoisons_memory),
> - KUNIT_CASE(ksize_uaf),
> KUNIT_CASE(kmem_cache_double_free),
> KUNIT_CASE(kmem_cache_invalid_free),
> KUNIT_CASE(kmem_cache_double_destroy),
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index 0e3648b603a6..0895c73e9b69 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -124,9 +124,7 @@ void kasan_unpoison(const void *addr, size_t size, bool
> init)
> addr = kasan_reset_tag(addr);
>
> /*
> -* Skip KFENCE memory if called explicitly outside of sl*b. Also note
> -* that calls to ksize(), where size is not a multiple of machine-word
> -* size, would otherwise poison the invalid portion of the word.
> +* Skip KFENCE memory if called explicitly outside of sl*b.
> */
> if (is_kfence_address(addr))
> return;
> --
> 2.34.1
Re: WARNING in drm_mode_createblob_ioctl
On Wed, Nov 6, 2019 at 4:28 PM Daniel Vetter wrote:
>
> On Wed, Nov 6, 2019 at 4:23 PM Daniel Vetter wrote:
> >
> > On Wed, Nov 6, 2019 at 4:20 PM syzbot
> > wrote:
> > >
> > > syzbot has bisected this bug to:
> > >
> > > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
> > > Author: Kees Cook
> > > Date: Mon Nov 4 22:57:23 2019 +
> > >
> > > uaccess: disallow > INT_MAX copy sizes
> >
> > Ah cool, this explains it.
> >
> > fwiw I never managed to get the WARNING in the backtrace to lign up
> > with any code. No idea what's been going on.
>
> Ok I think I have an idea, the above commit isn't in the linux-next I
> have here. Where is this from?
> -Daniel
You need to fetch tags to linux-next. syzbot started bisecting from
the commit where the crash happened, and it is now probably not the
current tag.
linux$ git show 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
Author: Kees Cook
Date: Tue Nov 5 09:57:23 2019 +1100
uaccess: disallow > INT_MAX copy sizes
As we've done with VFS, string operations, etc, reject usercopy sizes
larger than INT_MAX, which would be nice to have for catching bugs related
to size calculation overflows[1].
This adds 10 bytes to x86_64 defconfig text and 1980 bytes to the data
section:
textdata bss dec hex filename
196911675134320 1646664 26472151193eed7 vmlinux.before
196911775136300 1646664 26474141193f69d vmlinux.after
[1] https://marc.info/?l=linux-s390&m=156631939010493&w=2
Link: http://lkml.kernel.org/r/201908251612.F9902D7A@keescook
Signed-off-by: Kees Cook
Suggested-by: Dan Carpenter
Cc: Alexander Viro
Signed-off-by: Andrew Morton
Signed-off-by: Stephen Rothwell
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 659a4400517b2..e93e249a4e9bf 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -147,6 +147,8 @@ check_copy_size(const void *addr, size_t bytes,
bool is_source)
__bad_copy_to();
return false;
}
+ if (WARN_ON_ONCE(bytes > INT_MAX))
+ return false;
check_object_size(addr, bytes, is_source);
return true;
}
> > I'll type a patch to paper over this.
> > -Daniel
> >
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=125fe6dce0
> > > start commit: 51309b9d Add linux-next specific files for 20191105
> > > git tree: linux-next
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=115fe6dce0
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=165fe6dce0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae0
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae0
> > >
> > > Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> > > Fixes: 9e5a64c71b2f ("uaccess: disallow > INT_MAX copy sizes")
> > >
> > > For information about bisection process see:
> > > https://goo.gl/tpsmEJ#bisection
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_mode_createblob_ioctl
On Wed, Nov 6, 2019 at 4:30 PM Daniel Vetter wrote:
>
> On Wed, Nov 6, 2019 at 4:20 PM syzbot
> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
> > Author: Kees Cook
> > Date: Mon Nov 4 22:57:23 2019 +
> >
> > uaccess: disallow > INT_MAX copy sizes
>
> Ah cool, this explains it.
>
> fwiw I never managed to get the WARNING in the backtrace to lign up
> with any code. No idea what's been going on.
>
> I'll type a patch to paper over this.
> -Daniel
If I get:
git checkout 8ada228a
then include/linux/thread_info.h:150
points right to:
if (WARN_ON_ONCE(bytes > INT_MAX))
Is the size user-controllable here?
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=125fe6dce0
> > start commit: 51309b9d Add linux-next specific files for 20191105
> > git tree: linux-next
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=115fe6dce0
> > console output: https://syzkaller.appspot.com/x/log.txt?x=165fe6dce0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52
> > dashboard link: https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae0
> >
> > Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> > Fixes: 9e5a64c71b2f ("uaccess: disallow > INT_MAX copy sizes")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/CAKMK7uFQt%2B%3D7XMo9jvz77QvDWLAAU_V7-_qZ%3DiKe-GXG7cqeJg%40mail.gmail.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_mode_createblob_ioctl
On Mon, Oct 14, 2019 at 11:39 AM syzbot wrote: > > Op 14-10-2019 om 11:16 schreef Daniel Vetter: > > On Sun, Oct 13, 2019 at 11:09:09PM -0700, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit:8ada228a Add linux-next specific files for 20191011 > >> git tree: linux-next > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1423a87f60 > >> kernel config: https://syzkaller.appspot.com/x/.config?x=7cf4eed5fe42c31a > >> dashboard link: > >> https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914 > >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > >> > >> Unfortunately, I don't have any reproducer for this crash yet. > > Hm only thing that could go wrong is how we allocate the target for the > > user_copy, which is an argument directly from the ioctl parameter struct. > > Does syzbot not track that? We use the standard linux ioctl struct > > encoding in drm. > > > > Otherwise I have no idea why it can't create a reliable reproducer for > > this ... I'm also not seeing the bug, all the input validation we have > > seems correct :-/ > > I would like to see the entire dmesg? > > in particular because it's likely WARN(1, "Buffer overflow detected (%d < > %lu)!\n", size, count), > > so I'd like to see the size it thinks for both.. And who are "you"? :) The email as if comes from syzbot: From: syzbot But it is clearly not generated by syzbot code. Or is it some kind of a glitch?... Anyway, full console output is always referenced on every syzbot bug report as "console output:" link. > > -Daniel > >> IMPORTANT: if you fix the bug, please add the following tag to the commit: > >> Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com > >> > >> [ cut here ] > >> WARNING: CPU: 1 PID: 30449 at include/linux/thread_info.h:150 > >> check_copy_size include/linux/thread_info.h:150 [inline] > >> WARNING: CPU: 1 PID: 30449 at include/linux/thread_info.h:150 > >> copy_from_user > >> include/linux/uaccess.h:143 [inline] > >> WARNING: CPU: 1 PID: 30449 at include/linux/thread_info.h:150 > >> drm_mode_createblob_ioctl+0x398/0x490 drivers/gpu/drm/drm_property.c:800 > >> Kernel panic - not syncing: panic_on_warn set ... > >> CPU: 1 PID: 30449 Comm: syz-executor.5 Not tainted 5.4.0-rc2-next-20191011 > >> #0 > >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > >> Google 01/01/2011 > >> Call Trace: > >> __dump_stack lib/dump_stack.c:77 [inline] > >> dump_stack+0x172/0x1f0 lib/dump_stack.c:113 > >> panic+0x2e3/0x75c kernel/panic.c:221 > >> __warn.cold+0x2f/0x35 kernel/panic.c:582 > >> report_bug+0x289/0x300 lib/bug.c:195 > >> fixup_bug arch/x86/kernel/traps.c:174 [inline] > >> fixup_bug arch/x86/kernel/traps.c:169 [inline] > >> do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267 > >> do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286 > >> invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028 > >> RIP: 0010:check_copy_size include/linux/thread_info.h:150 [inline] > >> RIP: 0010:copy_from_user include/linux/uaccess.h:143 [inline] > >> RIP: 0010:drm_mode_createblob_ioctl+0x398/0x490 > >> drivers/gpu/drm/drm_property.c:800 > >> Code: c1 ea 03 80 3c 02 00 0f 85 ed 00 00 00 49 89 5d 00 e8 3c 28 cb fd 4c > >> 89 f7 e8 64 92 9e 03 31 c0 e9 75 fd ff ff e8 28 28 cb fd <0f> 0b e8 21 28 > >> cb > >> fd 4d 85 e4 b8 f2 ff ff ff 0f 84 5b fd ff ff 89 > >> RSP: 0018:8880584efaa8 EFLAGS: 00010246 > >> RAX: 0004 RBX: 8880a3a9 RCX: c900109da000 > >> RDX: 0004 RSI: 83a7eaf8 RDI: 0007 > >> RBP: 8880584efae8 R08: 888096c40080 R09: ed1014752110 > >> R10: ed101475210f R11: 8880a3a9087f R12: c90014907000 > >> R13: 888028aa R14: 9a6c7969 R15: c90014907058 > >> > >> > >> --- > >> This bug is generated by a bot. It may contain errors. > >> See https://goo.gl/tpsmEJ for more information about syzbot. > >> syzbot engineers can be reached at syzkal...@googlegroups.com. > >> > >> syzbot will keep track of this bug report. See: > >> https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/67fb1a91-7ef3-9036-2d1b-877e394bcab2%40linux.intel.com.
Re: BUG: unable to handle kernel paging request in ion_heap_clear_pages
On Sat, Nov 30, 2019 at 8:59 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:419593da Add linux-next specific files for 20191129 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12bfd882e0 > kernel config: https://syzkaller.appspot.com/x/.config?x=7c04b0959e75c206 > dashboard link: https://syzkaller.appspot.com/bug?extid=be6ccf3081ce8afd1b56 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+be6ccf3081ce8afd1...@syzkaller.appspotmail.com +Daniel, kasan-dev This is presumably from the new CONFIG_KASAN_VMALLOC and should be: #syz fix: kasan: support vmalloc backing of vm_map_ram() > BUG: unable to handle page fault for address: f52002e0 > #PF: supervisor read access in kernel mode > #PF: error_code(0x) - not-present page > PGD 21ffee067 P4D 21ffee067 PUD aa11c067 PMD 0 > Oops: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 3644 Comm: ion_system_heap Not tainted > 5.4.0-next-20191129-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline] > RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline] > RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline] > RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline] > RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192 > Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e > 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74 > ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80 > RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212 > RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229 > RDX: 0001 RSI: b000 RDI: c9001700 > RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600 > R10: f52002e015ff R11: c9001700afff R12: f52002e0 > R13: b000 R14: R15: c9000c9f7d08 > FS: () GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: f52002e0 CR3: 778bd000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > memset+0x24/0x40 mm/kasan/common.c:107 > memset include/linux/string.h:410 [inline] > ion_heap_clear_pages+0x49/0x70 drivers/staging/android/ion/ion_heap.c:106 > ion_heap_sglist_zero+0x245/0x270 drivers/staging/android/ion/ion_heap.c:130 > ion_heap_buffer_zero+0xf5/0x150 drivers/staging/android/ion/ion_heap.c:145 > ion_system_heap_free+0x1eb/0x250 > drivers/staging/android/ion/ion_system_heap.c:163 > ion_buffer_destroy+0x159/0x2d0 drivers/staging/android/ion/ion.c:93 > ion_heap_deferred_free+0x29d/0x630 > drivers/staging/android/ion/ion_heap.c:239 > kthread+0x361/0x430 kernel/kthread.c:255 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > Modules linked in: > CR2: f52002e0 > ---[ end trace ee5c63907f1d6f00 ]--- > RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline] > RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline] > RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline] > RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline] > RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192 > Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e > 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74 > ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80 > RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212 > RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229 > RDX: 0001 RSI: b000 RDI: c9001700 > RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600 > R10: f52002e015ff R11: c9001700afff R12: f52002e0 > R13: b000 R14: R15: c9000c9f7d08 > FS: () GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: f52002e0 CR3: 778bd000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On Tue, Dec 3, 2019 at 11:37 PM Daniel Vetter wrote: > > On Tue, Dec 3, 2019 at 11:25 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:76bb8b05 Merge tag 'kbuild-v5.5' of git://git.kernel.org/p.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=10bfe282e0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b > > dashboard link: https://syzkaller.appspot.com/bug?extid=4455ca3b3291de891abc > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11181edae0 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae0 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+4455ca3b3291de891...@syzkaller.appspotmail.com > > > > == > > BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:380 [inline] > > BUG: KASAN: slab-out-of-bounds in fbcon_get_font+0x2b2/0x5e0 > > drivers/video/fbdev/core/fbcon.c:2465 > > Read of size 16 at addr 888094b0aa10 by task syz-executor414/ > > So fbcon allocates some memory, security/tomoyo goes around and frees > it, fbcon goes boom because the memory is gone. I'm kinda leaning > towards "not an fbcon bug". Adding relevant security folks and mailing > lists. > > But from a very quick look in tomoyo it loosk more like "machine on > fire, random corruption all over". No idea what's going on here. Hi Daniel, This is an out-of-bounds access, not use-after-free. I don't know why we print the free stack at all (maybe +Andrey knows), but that's what KASAN did from day one. I filed https://bugzilla.kernel.org/show_bug.cgi?id=198425 which I think is a good idea, I will add your confusion as a data point :) Re this bug, free stack is irrelevant, I guess it's when the heap block was freed before it was reallocated by console. So it's plain out-of-bounds in fbcon_get_font, which looks sane and consistent to me and reproducible on top. > > CPU: 0 PID: Comm: syz-executor414 Not tainted 5.4.0-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Call Trace: > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0x197/0x210 lib/dump_stack.c:118 > > print_address_description.constprop.0.cold+0xd4/0x30b > > mm/kasan/report.c:374 > > __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 > > kasan_report+0x12/0x20 mm/kasan/common.c:638 > > check_memory_region_inline mm/kasan/generic.c:185 [inline] > > check_memory_region+0x134/0x1a0 mm/kasan/generic.c:192 > > memcpy+0x24/0x50 mm/kasan/common.c:124 > > memcpy include/linux/string.h:380 [inline] > > fbcon_get_font+0x2b2/0x5e0 drivers/video/fbdev/core/fbcon.c:2465 > > con_font_get drivers/tty/vt/vt.c:4446 [inline] > > con_font_op+0x20b/0x1250 drivers/tty/vt/vt.c:4605 > > vt_ioctl+0x181a/0x26d0 drivers/tty/vt/vt_ioctl.c:965 > > tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2658 > > vfs_ioctl fs/ioctl.c:47 [inline] > > file_ioctl fs/ioctl.c:545 [inline] > > do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 > > ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 > > __do_sys_ioctl fs/ioctl.c:756 [inline] > > __se_sys_ioctl fs/ioctl.c:754 [inline] > > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 > > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > RIP: 0033:0xd9 > > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > ff 0f 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7fff6f4393b8 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: 7fff6f4393c0 RCX: 00d9 > > RDX: 2440 RSI: 4b72 RDI: 0005 > > RBP: R08: R09: 00400da0 > > R10: 7fff6f438f00 R11: 0246 R12: 004021e0 > > R13: 00402270 R14: R15: > > > > Allocated by task : > > save_stack+0x23/0x90 mm/kasan/common.c:71 > > set_track mm/kasan/common.c:79 [inline] > > __kasan_kmalloc mm/kasan/common.c:512 [inline] > > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:485 > > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:526 > > __do_kmalloc mm/slab.c:3656 [inline] > > __kmalloc+0x163/0x770 mm/slab.c:3665 > > kmalloc include/linux/slab.h:561 [inline] > > fbcon_set_font+0x32d/0x860 drivers/video/fbdev/core/fbcon.c:2663 > > con_font_set drivers/tty/vt/vt.c:4538 [inline] > > con_font_op+0xe18/0x1250 drivers/tty/vt/vt.c:4603 > > vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913 > > tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2658 > > vfs_ioctl fs/ioctl.c:47 [inline] > > file_ioctl fs/ioctl.c:545 [inlin
cirrusfb: divide errors in cirrusfb_check_var/cirrusfb_check_pixclock/cirrusfb_set_par_foo
Hello, syzkaller has found 3 of divide errors in the cirrusfb driver. Kernel is on c5db92909bedd Add linux-next specific files for 20191202. divide error: [#1] PREEMPT SMP KASAN CPU: 0 PID: 8133 Comm: syz-executor.5 Not tainted 5.4.0-next-20191202+ #13 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:cirrusfb_set_par_foo+0x1d17/0x64b0 drivers/video/fbdev/cirrusfb.c:836 Call Trace: cirrusfb_set_par+0x15/0x20 drivers/video/fbdev/cirrusfb.c:1272 fb_set_var+0x518/0xdd0 drivers/video/fbdev/core/fbmem.c:1024 do_fb_ioctl+0x50c/0x830 drivers/video/fbdev/core/fbmem.c:1104 fb_ioctl+0xe6/0x130 drivers/video/fbdev/core/fbmem.c:1180 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x1df/0x1420 fs/ioctl.c:732 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:749 divide error: [#1] PREEMPT SMP KASAN CPU: 3 PID: 7639 Comm: syz-executor.0 Not tainted 5.4.0-next-20191202+ #12 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:cirrusfb_check_pixclock drivers/video/fbdev/cirrusfb.c:482 [inline] RIP: 0010:cirrusfb_check_var+0x6e8/0x1150 drivers/video/fbdev/cirrusfb.c:623 Call Trace: fb_set_var+0x236/0xdd0 drivers/video/fbdev/core/fbmem.c:1005 do_fb_ioctl+0x50c/0x830 drivers/video/fbdev/core/fbmem.c:1104 fb_ioctl+0xe6/0x130 drivers/video/fbdev/core/fbmem.c:1180 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x1df/0x1420 fs/ioctl.c:732 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:749 divide error: [#1] PREEMPT SMP KASAN CPU: 1 PID: 12555 Comm: syz-executor.5 Not tainted 5.4.0-next-20191202+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:cirrusfb_check_var.cold.16+0x12e/0x1e7 drivers/video/fbdev/cirrusfb.c:581 Call Trace: fb_set_var+0x236/0xdd0 drivers/video/fbdev/core/fbmem.c:1005 do_fb_ioctl+0x50c/0x830 drivers/video/fbdev/core/fbmem.c:1104 fb_ioctl+0xe6/0x130 drivers/video/fbdev/core/fbmem.c:1180 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x1df/0x1420 fs/ioctl.c:732 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:749 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
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 +
> >
> > powerpc/powernv: Remove support for p5ioc2
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127a042ae0
> > start commit: 76bb8b05 Merge tag 'kbuild-v5.5' of
> > git://git.kernel.org/p..
> > git tree: upstream
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=117a042ae0
> > console output: https://syzkaller.appspot.com/x/log.txt?x=167a042ae0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b
> > dashboard link:
> > https://syzkaller.appspot.com/bug?extid=4455ca3b3291de891abc
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11181edae0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae0
> >
> > Reported-by: syzbot+4455ca3b3291de891...@syzkaller.appspotmail.com
> > Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")
> >
> > For information about bisection process see:
> > https://goo.gl/tpsmEJ#bisection
> >
>
> Why is everybody being CC'd, even if the bug has nothing to do with the
> person's subsystem?
The To list should be intersection of 2 groups of emails: result of
get_maintainers.pl on the file identified as culprit in the crash
message + emails extracted from the bisected to commit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On Thu, Dec 5, 2019 at 11:53 AM Paolo Bonzini wrote: > > On 05/12/19 11:31, Dmitry Vyukov 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. :) > > I don't see any mention of "kvm" in the crash report. > > It's there in the stack trace, not sure if this is what triggered my Cc: > > [] kvm_wait+0xca/0xe0 arch/x86/kernel/kvm.c:612 > > Paolo Oh, you mean the final bisection crash. Indeed it contains a kvm frame and it turns out to be a bug in syzkaller code that indeed misattributed it to kvm instead of netfilter. Should be fixed now, you may read the commit message for details: https://github.com/google/syzkaller/commit/4fb74474cf0af2126be3a8989d770c3947ae9478 Overall this "making sense out of kernel output" task is the ultimate insanity, you may skim through this file to get a taste of amount of hardcoding and special corner cases that need to be handled: https://github.com/google/syzkaller/blob/master/pkg/report/linux.go And this is never done, such "exception from exception corner case" things pop up every week. There is always something to shuffle and tune. It only keeps functioning due to 500+ test cases for all possible insane kernel outputs: https://github.com/google/syzkaller/tree/master/pkg/report/testdata/linux/report https://github.com/google/syzkaller/tree/master/pkg/report/testdata/linux/guilty So thanks for persisting and questioning! We are getting better with each new test. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On Thu, Dec 5, 2019 at 11:41 AM Tetsuo Handa wrote: > > 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 architectures other than > > x86? > > > > It would be nice if coverage functionality can extract filenames in the source > code and supply the list of filenames as arguments for bisect operation. > > Also, (unrelated but) it would be nice if we can have "make yes2modconfig" > target which converts CONFIG_FOO=y to CONFIG_FOO=m if FOO is tristate. > syzbot is testing kernel configs close to "make allyesconfig" but I want to > save kernel rebuild time by disabling unrelated functionality when manually > "debug printk()ing" kernels. I thought that maybe sed "s#=y#=m#g" && make olddefconfig will do, but unfortunately, it turns off non-tristate configs... $ egrep "CONFIG_MEMORY_HOTPLUG|CONFIG_TCP_CONG_DCTCP" .config CONFIG_MEMORY_HOTPLUG=y CONFIG_TCP_CONG_DCTCP=y # sed -i "s/CONFIG_MEMORY_HOTPLUG=y/CONFIG_MEMORY_HOTPLUG=m/g" .config # sed -i "s/CONFIG_TCP_CONG_DCTCP=y/CONFIG_TCP_CONG_DCTCP=m/g" .config # egrep "CONFIG_MEMORY_HOTPLUG|CONFIG_TCP_CONG_DCTCP" .config CONFIG_MEMORY_HOTPLUG=m CONFIG_TCP_CONG_DCTCP=m # make olddefconfig # egrep "CONFIG_MEMORY_HOTPLUG|CONFIG_TCP_CONG_DCTCP" .config # CONFIG_MEMORY_HOTPLUG is not set CONFIG_TCP_CONG_DCTCP=m ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On Thu, Dec 5, 2019 at 11:22 AM Paolo Bonzini wrote:
>
> On 05/12/19 11: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 +
> >>>
> >>> powerpc/powernv: Remove support for p5ioc2
> >>>
> >>> bisection log:
> >>> https://syzkaller.appspot.com/x/bisect.txt?x=127a042ae0
> >>> start commit: 76bb8b05 Merge tag 'kbuild-v5.5' of
> >>> git://git.kernel.org/p..
> >>> git tree: upstream
> >>> final crash:
> >>> https://syzkaller.appspot.com/x/report.txt?x=117a042ae0
> >>> console output: https://syzkaller.appspot.com/x/log.txt?x=167a042ae0
> >>> kernel config: https://syzkaller.appspot.com/x/.config?x=dd226651cb0f364b
> >>> dashboard link:
> >>> https://syzkaller.appspot.com/bug?extid=4455ca3b3291de891abc
> >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11181edae0
> >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae0
> >>>
> >>> Reported-by: syzbot+4455ca3b3291de891...@syzkaller.appspotmail.com
> >>> Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")
> >>>
> >>> For information about bisection process see:
> >>> https://goo.gl/tpsmEJ#bisection
> >>>
> >>
> >> Why is everybody being CC'd, even if the bug has nothing to do with the
> >> person's subsystem?
> >
> > The To list should be intersection of 2 groups of emails: result of
> > get_maintainers.pl on the file identified as culprit in the crash
> > message + emails extracted from the bisected to commit.
>
> 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. :)
I don't see any mention of "kvm" in the crash report. And it's only 1
file, not all of them, in this case I would expect it to be
drivers/video/fbdev/core/fbcon.c. So it should be something different.
> This bisect result is bogus, though Tetsuo found the bug anyway.
> Perhaps you can exclude commits that only touch architectures other than
> x86?
We do this. It work sometimes. But sometimes it hits non-deterministic
kernel build bugs:
https://github.com/google/syzkaller/issues/1271#issuecomment-559093018
And in this case it hit some git bisect weirdness which I can't explain yet:
https://github.com/google/syzkaller/issues/1527
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: INFO: task hung in fb_open
On Thu, Dec 5, 2019 at 3:05 PM Daniel Vetter wrote:
>
> On Thu, Dec 5, 2019 at 2:38 PM syzbot
> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 979c11ef39cee79d6f556091a357890962be2580
> > Author: Ayan Kumar Halder
> > Date: Tue Jul 17 17:13:46 2018 +
> >
> > drm/sun4i: Substitute sun4i_backend_format_is_yuv() with format->is_yuv
>
> Pretty sure your GCD machine is not using the sun4i driver. It's also
> very far away from the code that's blowing up. bisect gone wrong?
> -Daniel
Yes, this driver is not even enabled in the config.
I see 2 issues with kernel in the bisect log:
1. Unrelated machine hangs get in the way of bisection process (or
that "no output" another manifestation of this bug?).
2. Somehow this change to not compiled file changed vmlinux thus
detection of unrelated changes failed. Non-deterministic kernel builds
issue is tracked here:
https://github.com/google/syzkaller/issues/1271#issuecomment-559093018
but so far I don't have any glues/ideas.
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15d2f97ee0
> > start commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13d2f97ee0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=7d8ab2e0e09c2a82
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a4ae1442ccc637162dc1
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14273edae0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e7677ae0
> >
> > Reported-by: syzbot+a4ae1442ccc637162...@syzkaller.appspotmail.com
> > Fixes: 979c11ef39ce ("drm/sun4i: Substitute sun4i_backend_format_is_yuv()
> > with format->is_yuv")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/CAKMK7uF4AR_tRxt5wBKxzz6gTPJmub3A%3Dxyuh1HjgvfYy7RCBg%40mail.gmail.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
On Thu, Dec 5, 2019 at 11:41 AM Tetsuo Handa wrote: > > 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 architectures other than > > x86? > > > > It would be nice if coverage functionality can extract filenames in the source > code and supply the list of filenames as arguments for bisect operation. What is the criteria for file name extraction? What will bisect operation do with the set of files? If you have a feature/improvement request, please file it at: https://github.com/google/syzkaller/issues/new ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: use-after-free Read in soft_cursor
On Fri, Dec 6, 2019 at 5:34 PM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
> Author: Russell Currey
> Date: Mon Feb 8 04:08:20 2016 +
>
> powerpc/powernv: Remove support for p5ioc2
Another weird one, I must be missing something obvious about how git
bisect works... I keep adding these to:
https://github.com/google/syzkaller/issues/1527
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1512d1bce0
> start commit: b0d4beaa Merge branch 'next.autofs' of git://git.kernel.or..
> git tree: upstream
> final crash:https://syzkaller.appspot.com/x/report.txt?x=1712d1bce0
> console output: https://syzkaller.appspot.com/x/log.txt?x=1312d1bce0
> kernel config: https://syzkaller.appspot.com/x/.config?x=f07a23020fd7d21a
> dashboard link: https://syzkaller.appspot.com/bug?extid=cf43fb300aa142fb024b
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1745a90ee0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1361042ae0
>
> Reported-by: syzbot+cf43fb300aa142fb0...@syzkaller.appspotmail.com
> Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/fdd04105990b9c93%40google.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dealock in drm_fb_helper_damage_work
Hi,
I am getting the following deadlock on reservation_ww_class_mutex
while trying to boot next-2022 kernel:
WARNING: possible recursive locking detected
6.1.0-rc4-next-2022 #193 Not tainted
kworker/4:1/81 is trying to acquire lock:
88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
dma_resv_lock_interruptible include/linux/dma-resv.h:372 [inline]
88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
ttm_bo_reserve include/drm/ttm/ttm_bo_driver.h:121 [inline]
88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
drm_gem_vram_vmap+0xa4/0x590 drivers/gpu/drm/drm_gem_vram_helper.c:436
but task is already holding lock:
88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
dma_resv_lock include/linux/dma-resv.h:345 [inline]
88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
drm_gem_vmap_unlocked+0x3f/0xa0 drivers/gpu/drm/drm_gem.c:1195
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(reservation_ww_class_mutex);
lock(reservation_ww_class_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/4:1/81:
#0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
#0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
atomic_long_set include/linux/atomic/atomic-instrumented.h:1280
[inline]
#0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
set_work_data kernel/workqueue.c:636 [inline]
#0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:663 [inline]
#0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x8e4/0x1720 kernel/workqueue.c:2260
#1: c9000694fda0
((work_completion)(&helper->damage_work)){+.+.}-{0:0}, at:
process_one_work+0x918/0x1720 kernel/workqueue.c:2264
#2: 88812ebe8278 (&helper->lock){+.+.}-{3:3}, at:
drm_fbdev_damage_blit drivers/gpu/drm/drm_fbdev_generic.c:312 [inline]
#2: 88812ebe8278 (&helper->lock){+.+.}-{3:3}, at:
drm_fbdev_fb_dirty+0x30e/0xcd0 drivers/gpu/drm/drm_fbdev_generic.c:342
#3: 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
dma_resv_lock include/linux/dma-resv.h:345 [inline]
#3: 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
drm_gem_vmap_unlocked+0x3f/0xa0 drivers/gpu/drm/drm_gem.c:1195
stack backtrace:
CPU: 4 PID: 81 Comm: kworker/4:1 Not tainted 6.1.0-rc4-next-2022 #193
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Workqueue: events drm_fb_helper_damage_work
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
print_deadlock_bug kernel/locking/lockdep.c:2990 [inline]
check_deadlock kernel/locking/lockdep.c:3033 [inline]
validate_chain kernel/locking/lockdep.c:3818 [inline]
__lock_acquire.cold+0x119/0x3b9 kernel/locking/lockdep.c:5055
lock_acquire kernel/locking/lockdep.c:5668 [inline]
lock_acquire+0x1e0/0x610 kernel/locking/lockdep.c:5633
__mutex_lock_common kernel/locking/mutex.c:603 [inline]
__ww_mutex_lock.constprop.0+0x1ba/0x2ee0 kernel/locking/mutex.c:754
ww_mutex_lock_interruptible+0x37/0x140 kernel/locking/mutex.c:886
dma_resv_lock_interruptible include/linux/dma-resv.h:372 [inline]
ttm_bo_reserve include/drm/ttm/ttm_bo_driver.h:121 [inline]
drm_gem_vram_vmap+0xa4/0x590 drivers/gpu/drm/drm_gem_vram_helper.c:436
drm_gem_vmap+0xc5/0x1b0 drivers/gpu/drm/drm_gem.c:1166
drm_gem_vmap_unlocked+0x4a/0xa0 drivers/gpu/drm/drm_gem.c:1196
drm_client_buffer_vmap+0x45/0xd0 drivers/gpu/drm/drm_client.c:326
drm_fbdev_damage_blit drivers/gpu/drm/drm_fbdev_generic.c:314 [inline]
drm_fbdev_fb_dirty+0x31e/0xcd0 drivers/gpu/drm/drm_fbdev_generic.c:342
drm_fb_helper_damage_work+0x27a/0x5d0 drivers/gpu/drm/drm_fb_helper.c:388
process_one_work+0xa33/0x1720 kernel/workqueue.c:2289
worker_thread+0x67d/0x10e0 kernel/workqueue.c:2436
kthread+0x2e4/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
The config is:
https://gist.githubusercontent.com/dvyukov/2897b21db809075a22db0370c495ed2d/raw/9b2535b2ba77bb57e4f1ba2b909ad4075b6e2c6a/gistfile1.txt
Qemu command line:
qemu-system-x86_64 -enable-kvm -machine q35,nvdimm -cpu
max,migratable=off -smp 18 \
-m 72G -hda buildroot-amd64-2021.08 -kernel arch/x86/boot/bzImage -nographic \
-net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic,model=virtio-net-pci \
-append "console=ttyS0 root=/dev/sda1 earlyprintk=serial rodata=n \
oops=panic panic_on_warn=1 panic=86400 coredump_filter=0x"
Re: dealock in drm_fb_helper_damage_work
On Sun, 13 Nov 2022 at 21:42, Dmitry Vyukov wrote:
>
> Hi,
>
> I am getting the following deadlock on reservation_ww_class_mutex
> while trying to boot next-2022 kernel:
The code is recently added by this commit:
commit 79e2cf2e7a193473dfb0da3b9b869682b43dc60f
Author: Dmitry Osipenko
Date: Mon Oct 17 20:22:11 2022 +0300
drm/gem: Take reservation lock for vmap/vunmap operations
>
> WARNING: possible recursive locking detected
> 6.1.0-rc4-next-2022 #193 Not tainted
>
> kworker/4:1/81 is trying to acquire lock:
> 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> dma_resv_lock_interruptible include/linux/dma-resv.h:372 [inline]
> 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> ttm_bo_reserve include/drm/ttm/ttm_bo_driver.h:121 [inline]
> 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> drm_gem_vram_vmap+0xa4/0x590 drivers/gpu/drm/drm_gem_vram_helper.c:436
>
> but task is already holding lock:
> 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> dma_resv_lock include/linux/dma-resv.h:345 [inline]
> 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> drm_gem_vmap_unlocked+0x3f/0xa0 drivers/gpu/drm/drm_gem.c:1195
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(reservation_ww_class_mutex);
> lock(reservation_ww_class_mutex);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 4 locks held by kworker/4:1/81:
> #0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
> arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
> #0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
> arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
> #0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
> atomic_long_set include/linux/atomic/atomic-instrumented.h:1280
> [inline]
> #0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
> set_work_data kernel/workqueue.c:636 [inline]
> #0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
> set_work_pool_and_clear_pending kernel/workqueue.c:663 [inline]
> #0: 888100078d38 ((wq_completion)events){+.+.}-{0:0}, at:
> process_one_work+0x8e4/0x1720 kernel/workqueue.c:2260
> #1: c9000694fda0
> ((work_completion)(&helper->damage_work)){+.+.}-{0:0}, at:
> process_one_work+0x918/0x1720 kernel/workqueue.c:2264
> #2: 88812ebe8278 (&helper->lock){+.+.}-{3:3}, at:
> drm_fbdev_damage_blit drivers/gpu/drm/drm_fbdev_generic.c:312 [inline]
> #2: 88812ebe8278 (&helper->lock){+.+.}-{3:3}, at:
> drm_fbdev_fb_dirty+0x30e/0xcd0 drivers/gpu/drm/drm_fbdev_generic.c:342
> #3: 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> dma_resv_lock include/linux/dma-resv.h:345 [inline]
> #3: 88812ebe89a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at:
> drm_gem_vmap_unlocked+0x3f/0xa0 drivers/gpu/drm/drm_gem.c:1195
>
> stack backtrace:
> CPU: 4 PID: 81 Comm: kworker/4:1 Not tainted 6.1.0-rc4-next-2022 #193
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> Workqueue: events drm_fb_helper_damage_work
> Call Trace:
>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
> print_deadlock_bug kernel/locking/lockdep.c:2990 [inline]
> check_deadlock kernel/locking/lockdep.c:3033 [inline]
> validate_chain kernel/locking/lockdep.c:3818 [inline]
> __lock_acquire.cold+0x119/0x3b9 kernel/locking/lockdep.c:5055
> lock_acquire kernel/locking/lockdep.c:5668 [inline]
> lock_acquire+0x1e0/0x610 kernel/locking/lockdep.c:5633
> __mutex_lock_common kernel/locking/mutex.c:603 [inline]
> __ww_mutex_lock.constprop.0+0x1ba/0x2ee0 kernel/locking/mutex.c:754
> ww_mutex_lock_interruptible+0x37/0x140 kernel/locking/mutex.c:886
> dma_resv_lock_interruptible include/linux/dma-resv.h:372 [inline]
> ttm_bo_reserve include/drm/ttm/ttm_bo_driver.h:121 [inline]
> drm_gem_vram_vmap+0xa4/0x590 drivers/gpu/drm/drm_gem_vram_helper.c:436
> drm_gem_vmap+0xc5/0x1b0 drivers/gpu/drm/drm_gem.c:1166
> drm_gem_vmap_unlocked+0x4a/0xa0 drivers/gpu/drm/drm_gem.c:1196
> drm_client_buffer_vmap+0x45/0xd0 drivers/gpu/drm/drm_client.c:326
> drm_fbdev_damage_blit drivers/gpu/drm/drm_fbdev_generic.c:314 [inline]
> drm_fbdev_fb_dirty+0x31e/0xcd0 drivers/gpu/drm/drm_fbdev_generic.c:342
> drm_fb_helper_damage_work+0x27a/0x5d0 drivers/gpu/drm/drm_fb_helper.c:388
> process_one_work+0xa33/0x1720 kernel/workqueue.c:2289
> worker_thread+0x67d/0x10e0 kernel/workqueue.c:2436
>
Re: [syzbot] [dri?] general protection fault in drm_crtc_next_vblank_start
On Mon, 3 Apr 2023 at 18:26, Rob Clark wrote:
>
> On Mon, Apr 3, 2023 at 12:57 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:a6d9e3034536 Add linux-next specific files for 20230330
> > git tree: linux-next
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=1001d1cdc8
> > kernel config: https://syzkaller.appspot.com/x/.config?x=aceb117f7924508e
> > dashboard link: https://syzkaller.appspot.com/bug?extid=54280c5aea19802490b5
> > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils
> > for Debian) 2.35.2
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13435a2ec8
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=139c9c21c8
> >
> > Downloadable assets:
> > disk image:
> > https://storage.googleapis.com/syzbot-assets/ec1f900ea929/disk-a6d9e303.raw.xz
> > vmlinux:
> > https://storage.googleapis.com/syzbot-assets/fabbf89c0d22/vmlinux-a6d9e303.xz
> > kernel image:
> > https://storage.googleapis.com/syzbot-assets/1ed05d6192fa/bzImage-a6d9e303.xz
> >
> > The issue was bisected to:
> >
> > commit d39e48ca80c0960b039cb38633957f0040f63e1a
> > Author: Rob Clark
> > Date: Fri Sep 3 18:47:54 2021 +
> >
> > drm/atomic-helper: Set fence deadline for vblank
> >
>
> should be fixed by https://patchwork.freedesktop.org/series/115992/
Let's tell syzbot about the fix so that it reports similar crashes in future:
#syz fix: drm/vblank: Fix for drivers that do not drm_vblank_init()
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d260c9c8
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=11d260c9c8
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16d260c9c8
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+54280c5aea1980249...@syzkaller.appspotmail.com
> > Fixes: d39e48ca80c0 ("drm/atomic-helper: Set fence deadline for vblank")
> >
> > [drm] Initialized udl 0.0.1 20120220 for 1-1:0.0 on minor 2
> > [drm] Initialized udl on minor 2
> > udl 1-1:0.0: [drm] *ERROR* Read EDID byte 0 failed err ffb9
> > udl 1-1:0.0: [drm] Cannot find any crtc or sizes
> > general protection fault, probably for non-canonical address
> > 0xdc28: [#1] PREEMPT SMP KASAN
> > KASAN: null-ptr-deref in range [0x0140-0x0147]
> > CPU: 0 PID: 9 Comm: kworker/0:1 Not tainted
> > 6.3.0-rc4-next-20230330-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 03/02/2023
> > Workqueue: usb_hub_wq hub_event
> > RIP: 0010:drm_crtc_next_vblank_start+0xb3/0x2b0
> > drivers/gpu/drm/drm_vblank.c:1003
> > Code: e8 01 00 00 48 69 db 38 02 00 00 48 b8 00 00 00 00 00 fc ff df 49 03
> > 9d 38 03 00 00 4c 8d ab 44 01 00 00 4c 89 ea 48 c1 ea 03 <0f> b6 14 02 4c
> > 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 67
> > RSP: 0018:c90e6bb0 EFLAGS: 00010207
> > RAX: dc00 RBX: RCX:
> > RDX: 0028 RSI: 849f2afb RDI: 888079558338
> > RBP: c90e6c48 R08: 0005 R09:
> > R10: 0001 R11: 0010 R12: 8880795590d8
> > R13: 0144 R14: 8880795590d8 R15: dc00
> > FS: () GS:8880b980() knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 7f17191c7688 CR3: 281af000 CR4: 003506f0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> >
> > set_fence_deadline drivers/gpu/drm/drm_atomic_helper.c:1531 [inline]
> > drm_atomic_helper_wait_for_fences+0x1b4/0x780
> > drivers/gpu/drm/drm_atomic_helper.c:1578
> > drm_atomic_helper_commit drivers/gpu/drm/drm_atomic_helper.c:2007 [inline]
> > drm_atomic_helper_commit+0x1bd/0x370
> > drivers/gpu/drm/drm_atomic_helper.c:1979
> > drm_atomic_commit+0x20a/0x300 drivers/gpu/drm/drm_atomic.c:1503
> > drm_client_modeset_commit_atomic+0x69b/0x7e0
> > drivers/gpu/drm/drm_client_modeset.c:1045
> > drm_client_modeset_commit_locked+0x149/0x580
> > drivers/gpu/drm/drm_client_modeset.c:1148
> > drm_client_modeset_commit+0x51/0x80
> > drivers/gpu/drm/drm_client_modeset.c:1174
> > drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1983 [inline]
> > __drm_fb_helper_initial_config_and_unlock+0x118a/0x1510
> > drivers/gpu/drm/drm_fb_helper.c:2169
> > drm_fb_helper_initial_config drivers/gpu/drm/drm_fb_helper.c:2259 [inline]
> > drm_fb_helper_initial_config+0x42/0x60 drivers/gpu/drm/drm_fb_helper.c:2251
> > drm_fbdev_generic_client_hotplug+0x1ab/0x270
> > drivers/gpu/drm/drm_fbdev_generic.c:281
> > drm_fbdev_generic_setup+0x127/0x3b0 drivers/gpu/drm/drm_fbdev_generic.c:343
> > udl_usb_probe+0x120/0x190 drivers/gpu/drm/udl/udl_drv.c:120
> >
Re: [syzbot] kernel BUG in vmf_insert_pfn_prot
On Tue, 13 Jun 2023 at 21:23, syzbot wrote: > > syzbot suspects this issue was fixed by commit: > > commit a5b44c4adb1699661d22e5152fb26885f30a2e4c > Author: Thomas Zimmermann > Date: Mon Mar 20 15:07:44 2023 + > > drm/fbdev-generic: Always use shadow buffering > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1025ee0728 > start commit: 0326074ff465 Merge tag 'net-next-6.1' of git://git.kernel... > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=d323d85b1f8a4ed7 > dashboard link: https://syzkaller.appspot.com/bug?extid=2d4f8693f438d2bd4bdb > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14fd118288 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1756751488 > > If the result looks correct, please mark the issue as fixed by replying with: > > #syz fix: drm/fbdev-generic: Always use shadow buffering > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection Looks reasonable: #syz fix: drm/fbdev-generic: Always use shadow buffering
[PATCH v2] drivers/gpu/vga: allocate vga_arb_write() buffer on stack
Size of kmalloc() in vga_arb_write() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Allocate the buffer on stack to avoid the WARNING.
The string must be small (e.g "target PCI:domain:bus:dev.fn").
Signed-off-by: Dmitry Vyukov
Reviewed-by: Ville Syrjälä
Cc: Dave Airlie
Cc: Ville Syrjälä
Cc: dri-devel at lists.freedesktop.org
Cc: syzkaller at googlegroups.com
---
Changes since v1:
- removed another kfree(kbuf)
I've sent a patch that adds __GFP_NOWARN to the kmalloc a while ago:
https://groups.google.com/forum/#!msg/syzkaller/navdAwe4iCo/mZDhODsnAAAJ
Ville suggested to allocate the buffer on stack as it must be small:
"From the looks of things the longest command could be the
"target PCI:domain:bus:dev.fn" thing. Even assuming something silly like
having 10 characters for each domain,bus,dev,fn that would still be only
55 bytes. So based on that even something like 64 bytes should be more
than enough AFAICS. "
Example WARNING:
WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999
__alloc_pages_nodemask+0x7d2/0x1760()
Modules linked in:
CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
880069eff670 8299a06d
8800658a4740 864985a0 880069eff6b0 8134fcf9
8166de32 864985a0 0bb7 024040c0
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
[] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
[] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
[< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999
[] __alloc_pages_nodemask+0x7d2/0x1760 mm/page_alloc.c:3253
[] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090
[< inline >] alloc_pages include/linux/gfp.h:459
[] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433
[] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008
[] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019
[< inline >] kmalloc_large include/linux/slab.h:395
[] __kmalloc+0x2f4/0x340 mm/slub.c:3557
[< inline >] kmalloc include/linux/slab.h:468
[] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926
[] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719
[] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849
[] vfs_writev+0x86/0xc0 fs/read_write.c:886
[< inline >] SYSC_writev fs/read_write.c:919
[] SyS_writev+0x111/0x2b0 fs/read_write.c:911
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---
drivers/gpu/vga/vgaarb.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 1887f19..77657a8 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -1022,21 +1022,16 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
unsigned int io_state;
- char *kbuf, *curr_pos;
+ char kbuf[64], *curr_pos;
size_t remaining = count;
int ret_val;
int i;
-
- kbuf = kmalloc(count + 1, GFP_KERNEL);
- if (!kbuf)
- return -ENOMEM;
-
- if (copy_from_user(kbuf, buf, count)) {
- kfree(kbuf);
+ if (count >= sizeof(kbuf))
+ return -EINVAL;
+ if (copy_from_user(kbuf, buf, count))
return -EFAULT;
- }
curr_pos = kbuf;
kbuf[count] = '\0'; /* Just to make sure... */
@@ -1259,11 +1254,9 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
goto done;
}
/* If we got here, the message written is not part of the protocol! */
- kfree(kbuf);
return -EPROTO;
done:
- kfree(kbuf);
return ret_val;
}
--
2.8.0.rc3.226.g39d4020
[PATCH] drivers/gpu/vga: allocate vga_arb_write() buffer on stack
On Fri, Oct 14, 2016 at 3:06 PM, Ville Syrjälä
wrote:
> On Fri, Oct 14, 2016 at 02:54:59PM +0200, Dmitry Vyukov wrote:
>> Size of kmalloc() in vga_arb_write() is controlled by user.
>> Too large kmalloc() size triggers WARNING message on console.
>> Allocate the buffer on stack to avoid the WARNING.
>> The string must be small (e.g "target PCI:domain:bus:dev.fn").
>>
>> Signed-off-by: Dmitry Vyukov
>> Cc: Dave Airlie
>> Cc: Ville Syrjälä
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: syzkaller at googlegroups.com
>>
>> --
>>
>> I've sent a patch that adds __GFP_NOWARN to the kmalloc a while ago:
>> https://groups.google.com/forum/#!msg/syzkaller/navdAwe4iCo/mZDhODsnAAAJ
>>
>> Ville suggested to allocate the buffer on stack as it must be small:
>>
>> "From the looks of things the longest command could be the
>> "target PCI:domain:bus:dev.fn" thing. Even assuming something silly like
>> having 10 characters for each domain,bus,dev,fn that would still be only
>> 55 bytes. So based on that even something like 64 bytes should be more
>> than enough AFAICS. "
>
>>
>> Example WARNING:
>>
>> WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999
>> __alloc_pages_nodemask+0x7d2/0x1760()
>> Modules linked in:
>> CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> 880069eff670 8299a06d
>> 8800658a4740 864985a0 880069eff6b0 8134fcf9
>> 8166de32 864985a0 0bb7 024040c0
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>> [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
>> [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
>> [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999
>> [] __alloc_pages_nodemask+0x7d2/0x1760
>> mm/page_alloc.c:3253
>> [] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090
>> [< inline >] alloc_pages include/linux/gfp.h:459
>> [] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433
>> [] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008
>> [] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019
>> [< inline >] kmalloc_large include/linux/slab.h:395
>> [] __kmalloc+0x2f4/0x340 mm/slub.c:3557
>> [< inline >] kmalloc include/linux/slab.h:468
>> [] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926
>> [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719
>> [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849
>> [] vfs_writev+0x86/0xc0 fs/read_write.c:886
>> [< inline >] SYSC_writev fs/read_write.c:919
>> [] SyS_writev+0x111/0x2b0 fs/read_write.c:911
>> [] entry_SYSCALL_64_fastpath+0x16/0x7a
>> arch/x86/entry/entry_64.S:185
>> ---
>> drivers/gpu/vga/vgaarb.c | 11 +++
>> 1 file changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
>> index 1887f19..0c73083 100644
>> --- a/drivers/gpu/vga/vgaarb.c
>> +++ b/drivers/gpu/vga/vgaarb.c
>> @@ -1022,17 +1022,14 @@ static ssize_t vga_arb_write(struct file *file,
>> const char __user *buf,
>>
>> unsigned int io_state;
>>
>> - char *kbuf, *curr_pos;
>> + char kbuf[64], *curr_pos;
>> size_t remaining = count;
>>
>> int ret_val;
>> int i;
>>
>> -
>> - kbuf = kmalloc(count + 1, GFP_KERNEL);
>> - if (!kbuf)
>> - return -ENOMEM;
>> -
>> + if (count >= sizeof(kbuf))
>> + return -EINVAL;
>> if (copy_from_user(kbuf, buf, count)) {
>> kfree(kbuf);
>
> You missed one kfree() here.
Ouch!
> Assuming my analysis of the max string length wasn't full of crap
> I think this looks fine otherwise.
>
> So with the lingering kfree() nuked this is
> Reviewed-by: Ville Syrjälä
Mailed v2.
Thanks!
>> return -EFAULT;
>> @@ -1259,11 +1256,9 @@ static ssize_t vga_arb_write(struct file *file, const
>> char __user *buf,
>> goto done;
>> }
>> /* If we got here, the message written is not part of the protocol! */
>> - kfree(kbuf);
>> return -EPROTO;
>>
>> done:
>> - kfree(kbuf);
>> return ret_val;
>> }
>>
>> --
>> 2.8.0.rc3.226.g39d4020
>
> --
> Ville Syrjälä
> Intel OTC
[PATCH] drivers/gpu/vga: allocate vga_arb_write() buffer on stack
Size of kmalloc() in vga_arb_write() is controlled by user.
Too large kmalloc() size triggers WARNING message on console.
Allocate the buffer on stack to avoid the WARNING.
The string must be small (e.g "target PCI:domain:bus:dev.fn").
Signed-off-by: Dmitry Vyukov
Cc: Dave Airlie
Cc: Ville Syrjälä
Cc: dri-devel at lists.freedesktop.org
Cc: syzkaller at googlegroups.com
--
I've sent a patch that adds __GFP_NOWARN to the kmalloc a while ago:
https://groups.google.com/forum/#!msg/syzkaller/navdAwe4iCo/mZDhODsnAAAJ
Ville suggested to allocate the buffer on stack as it must be small:
"From the looks of things the longest command could be the
"target PCI:domain:bus:dev.fn" thing. Even assuming something silly like
having 10 characters for each domain,bus,dev,fn that would still be only
55 bytes. So based on that even something like 64 bytes should be more
than enough AFAICS. "
Example WARNING:
WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999
__alloc_pages_nodemask+0x7d2/0x1760()
Modules linked in:
CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
880069eff670 8299a06d
8800658a4740 864985a0 880069eff6b0 8134fcf9
8166de32 864985a0 0bb7 024040c0
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
[] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
[] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
[< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999
[] __alloc_pages_nodemask+0x7d2/0x1760 mm/page_alloc.c:3253
[] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090
[< inline >] alloc_pages include/linux/gfp.h:459
[] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433
[] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008
[] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019
[< inline >] kmalloc_large include/linux/slab.h:395
[] __kmalloc+0x2f4/0x340 mm/slub.c:3557
[< inline >] kmalloc include/linux/slab.h:468
[] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926
[] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719
[] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849
[] vfs_writev+0x86/0xc0 fs/read_write.c:886
[< inline >] SYSC_writev fs/read_write.c:919
[] SyS_writev+0x111/0x2b0 fs/read_write.c:911
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---
drivers/gpu/vga/vgaarb.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 1887f19..0c73083 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -1022,17 +1022,14 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
unsigned int io_state;
- char *kbuf, *curr_pos;
+ char kbuf[64], *curr_pos;
size_t remaining = count;
int ret_val;
int i;
-
- kbuf = kmalloc(count + 1, GFP_KERNEL);
- if (!kbuf)
- return -ENOMEM;
-
+ if (count >= sizeof(kbuf))
+ return -EINVAL;
if (copy_from_user(kbuf, buf, count)) {
kfree(kbuf);
return -EFAULT;
@@ -1259,11 +1256,9 @@ static ssize_t vga_arb_write(struct file *file, const
char __user *buf,
goto done;
}
/* If we got here, the message written is not part of the protocol! */
- kfree(kbuf);
return -EPROTO;
done:
- kfree(kbuf);
return ret_val;
}
--
2.8.0.rc3.226.g39d4020
[PATCH v2] drivers/gpu/vga: allocate vga_arb_write() buffer on stack
On Fri, Oct 14, 2016 at 3:22 PM, Dmitry Vyukov wrote:
> Size of kmalloc() in vga_arb_write() is controlled by user.
> Too large kmalloc() size triggers WARNING message on console.
> Allocate the buffer on stack to avoid the WARNING.
> The string must be small (e.g "target PCI:domain:bus:dev.fn").
>
> Signed-off-by: Dmitry Vyukov
> Reviewed-by: Ville Syrjälä
> Cc: Dave Airlie
> Cc: Ville Syrjälä
> Cc: dri-devel at lists.freedesktop.org
> Cc: syzkaller at googlegroups.com
Ping, this is still not merged.
David, please take this to dri tree.
> ---
>
> Changes since v1:
> - removed another kfree(kbuf)
>
> I've sent a patch that adds __GFP_NOWARN to the kmalloc a while ago:
> https://groups.google.com/forum/#!msg/syzkaller/navdAwe4iCo/mZDhODsnAAAJ
>
> Ville suggested to allocate the buffer on stack as it must be small:
>
> "From the looks of things the longest command could be the
> "target PCI:domain:bus:dev.fn" thing. Even assuming something silly like
> having 10 characters for each domain,bus,dev,fn that would still be only
> 55 bytes. So based on that even something like 64 bytes should be more
> than enough AFAICS. "
>
> Example WARNING:
>
> WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999
> __alloc_pages_nodemask+0x7d2/0x1760()
> Modules linked in:
> CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 880069eff670 8299a06d
> 8800658a4740 864985a0 880069eff6b0 8134fcf9
> 8166de32 864985a0 0bb7 024040c0
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
> [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
> [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
> [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999
> [] __alloc_pages_nodemask+0x7d2/0x1760 mm/page_alloc.c:3253
> [] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090
> [< inline >] alloc_pages include/linux/gfp.h:459
> [] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433
> [] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008
> [] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019
> [< inline >] kmalloc_large include/linux/slab.h:395
> [] __kmalloc+0x2f4/0x340 mm/slub.c:3557
> [< inline >] kmalloc include/linux/slab.h:468
> [] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926
> [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719
> [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849
> [] vfs_writev+0x86/0xc0 fs/read_write.c:886
> [< inline >] SYSC_writev fs/read_write.c:919
> [] SyS_writev+0x111/0x2b0 fs/read_write.c:911
> [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> ---
> drivers/gpu/vga/vgaarb.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 1887f19..77657a8 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -1022,21 +1022,16 @@ static ssize_t vga_arb_write(struct file *file, const
> char __user *buf,
>
> unsigned int io_state;
>
> - char *kbuf, *curr_pos;
> + char kbuf[64], *curr_pos;
> size_t remaining = count;
>
> int ret_val;
> int i;
>
> -
> - kbuf = kmalloc(count + 1, GFP_KERNEL);
> - if (!kbuf)
> - return -ENOMEM;
> -
> - if (copy_from_user(kbuf, buf, count)) {
> - kfree(kbuf);
> + if (count >= sizeof(kbuf))
> + return -EINVAL;
> + if (copy_from_user(kbuf, buf, count))
> return -EFAULT;
> - }
> curr_pos = kbuf;
> kbuf[count] = '\0'; /* Just to make sure... */
>
> @@ -1259,11 +1254,9 @@ static ssize_t vga_arb_write(struct file *file, const
> char __user *buf,
> goto done;
> }
> /* If we got here, the message written is not part of the protocol! */
> - kfree(kbuf);
> return -EPROTO;
>
> done:
> - kfree(kbuf);
> return ret_val;
> }
>
> --
> 2.8.0.rc3.226.g39d4020
>
drm: GPF in drm_getcap
On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in drm_getcap:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> uint64_t data[2] = {0x11, 0x80};
> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
> return 0;
> }
>
>
> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 8800310dc540 task.stack: 88003cbc
> RIP: 0010:[] []
> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
> R13: dc00 R14: 88003bcc6850 R15: fff2
> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 006dce00 CR3: 66135000 CR4: 06e0
> DR0: 001e DR1: 001e DR2:
> DR3: DR6: 0ff0 DR7: 0600
> Stack:
> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
> fff2 88003cbc7dc0 834cb57c e200
> 1101 875a1ba0 882ae930 0010
> Call Trace:
> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] entry_SYSCALL_64_fastpath+0x23/0xc1
> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
> RIP [] drm_getcap+0x34b/0x4f0
> drivers/gpu/drm/drm_ioctl.c:260
> RSP
> ---[ end trace c6e1afa8cd73b880 ]---
>
>
> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
ping
Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
drm: GPF in drm_getcap
grep "card0" dmesg:
[5.298617] device: 'card0': device_add
[5.298946] PM: Adding info for No Bus:card0
[6.436178] device: 'card0': device_add
[6.436488] PM: Adding info for No Bus:card0
# ls -l /dev/dri/card0
crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
# ls -lt /sys/class/drm/card0/device/
ls: cannot access /sys/class/drm/card0/device/: No such file or directory
# ls -lt /sys/class/drm/card0/device/driver
ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
On Sat, Nov 26, 2016 at 7:02 PM, David Herrmann
wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov wrote:
>> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
>> wrote:
>>> Hi
>>>
>>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov
>>> wrote:
>>>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> The following program triggers GPF in drm_getcap:
>>>>>
>>>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>> #include
>>>>>
>>>>> int main()
>>>>> {
>>>>> int fd = open("/dev/dri/card0", O_RDONLY);
>>>>> uint64_t data[2] = {0x11, 0x80};
>>>>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>>>> return 0;
>>>>> }
>>>>>
>>>>>
>>>>> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
>>>>> Modules linked in:
>>>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+
>>>>> #14
>>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>>>>> 01/01/2011
>>>>> task: 8800310dc540 task.stack: 88003cbc
>>>>> RIP: 0010:[] []
>>>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>>>> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
>>>>> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
>>>>> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
>>>>> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
>>>>> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
>>>>> R13: dc00 R14: 88003bcc6850 R15: fff2
>>>>> FS: 7fcbf4e03700() GS:88003ed0()
>>>>> knlGS:
>>>>> CS: 0010 DS: ES: CR0: 80050033
>>>>> CR2: 006dce00 CR3: 66135000 CR4: 06e0
>>>>> DR0: 001e DR1: 001e DR2:
>>>>> DR3: DR6: 0ff0 DR7: 0600
>>>>> Stack:
>>>>> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
>>>>> fff2 88003cbc7dc0 834cb57c e200
>>>>> 1101 875a1ba0 882ae930 0010
>>>>> Call Trace:
>>>>> [] drm_ioctl+0x54c/0xaf0
>>>>> drivers/gpu/drm/drm_ioctl.c:728
>>>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>>>> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>>>> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>>>> [] entry_SYSCALL_64_fastpath+0x23/0xc1
>>>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>>>> RIP [] drm_getcap+0x34b/0x4f0
>>>>> drivers/gpu/drm/drm_ioctl.c:260
>>>>> RSP
>>>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>>>
>>>>>
>>>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>>>
>>>> ping
>>>>
>>>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>>
>>> I suspect this is because we run drm_for_each_crtc() in
>>> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
>>> mode_config is not initialized). @danvet, how about always
>>> initializing mode_config to 0/empty/dummy?
>>>
>>> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
>>
>>
>> CONFIG_DRM_LEGACY is enabled.
>>
>> How can I understand what driver is used?
>> This happens inside of qemu. This is the device:
>> crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
>
> Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
>
> /sys/class/drm/card0/device/
>
> or more importantly looking at the symlink:
>
> /sys/class/drm/card0/device/driver
>
> Thanks
> David
drm: GPF in drm_getcap
On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> The following program triggers GPF in drm_getcap:
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> int main()
>>> {
>>> int fd = open("/dev/dri/card0", O_RDONLY);
>>> uint64_t data[2] = {0x11, 0x80};
>>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>> return 0;
>>> }
>>>
>>>
>>> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
>>> Modules linked in:
>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: 8800310dc540 task.stack: 88003cbc
>>> RIP: 0010:[] []
>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
>>> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
>>> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
>>> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
>>> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
>>> R13: dc00 R14: 88003bcc6850 R15: fff2
>>> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
>>> CS: 0010 DS: ES: CR0: 80050033
>>> CR2: 006dce00 CR3: 66135000 CR4: 06e0
>>> DR0: 001e DR1: 001e DR2:
>>> DR3: DR6: 0ff0 DR7: 0600
>>> Stack:
>>> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
>>> fff2 88003cbc7dc0 834cb57c e200
>>> 1101 875a1ba0 882ae930 0010
>>> Call Trace:
>>> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>> [] entry_SYSCALL_64_fastpath+0x23/0xc1
>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>> RIP [] drm_getcap+0x34b/0x4f0
>>> drivers/gpu/drm/drm_ioctl.c:260
>>> RSP
>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>
>>>
>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>
>> ping
>>
>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> I suspect this is because we run drm_for_each_crtc() in
> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
> mode_config is not initialized). @danvet, how about always
> initializing mode_config to 0/empty/dummy?
>
> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
CONFIG_DRM_LEGACY is enabled.
How can I understand what driver is used?
This happens inside of qemu. This is the device:
crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
drm: GPF in drm_getcap
On Mon, Nov 28, 2016 at 8:14 AM, Michel Dänzer wrote: > On 28/11/16 03:55 PM, Daniel Vetter wrote: >> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann >> wrote: >>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov >>> wrote: >>>> grep "card0" dmesg: >>>> [5.298617] device: 'card0': device_add >>>> [5.298946] PM: Adding info for No Bus:card0 >>>> [6.436178] device: 'card0': device_add >>>> [6.436488] PM: Adding info for No Bus:card0 >>>> >>>> >>>> # ls -l /dev/dri/card0 >>>> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 >>>> >>>> # ls -lt /sys/class/drm/card0/device/ >>>> ls: cannot access /sys/class/drm/card0/device/: No such file or directory >>>> >>>> # ls -lt /sys/class/drm/card0/device/driver >>>> ls: cannot access /sys/class/drm/card0/device/driver: No such file or >>>> directory >>> >>> Looks like vgem. Something like this should help: >>> >>> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 >>> >>> I wonder whether it would be more appropriate to return -ENOTSUPP rather >>> than 0. > > Can't see how that would matter FWIW. > > >> Seems a bit overkill, but can't hurt. This is most likely a >> regression, probably introduced in >> >> commit f837297ad82480024d3ad08cd84f6670bcafa862 >> Author: Michel Dänzer >> Date: Mon Aug 8 16:23:39 2016 +0900 >> >> drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2 >> >> Michel, can you pls take care of this? Either with a minimal fix, or >> by adopting David's patch? > > Can't we just use David's patch as-is? If not, I think Dmitry or someone > else would be better equipped than me to extract a minimal fix from it > and test it. I know nothing about DRM code. Reproducer is attached to the first email.
drm: WARNING in ioremap_wc
On Mon, Aug 29, 2016 at 8:05 AM, Daniel Vetter wrote:
> On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers WARNING in ioremap_wc:
>
> Yup, that should also be fixed in linux-next. Probably better to not
> report more for 4.8-rc kernels for now ;-)
>
> If you have some time to test, you need to cherry pick the following two
> patches I think:
>
> fa5386459f06 ("drm: Used DRM_LEGACY for all legacy functions")
> 3cbf6a5deb2f ("drm: Mark up legacy/dri1 drivers with DRM_LEGACY")
>
> If that's confirmed we can cherry-pick them over to -fixes.
Hi Daniel,
I've switched to linux-next and don't see the WARNINGs anymore.
I wonder how they were discovered? Is somebody else running syzkaller?
Or they were discovered in some other way?
Thanks
drm: NULL pointer dereference in drm_mode_object_find()
On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko
wrote:
> Hello,
>
> the program below triggers a NULL deref in DRM code when ran on QEMU:
>
> ===
> BUG: unable to handle kernel NULL pointer dereference at (null)
> IP: [< inline >] __list_add ./include/linux/list.h:44
> IP: [< inline >] list_add_tail ./include/linux/list.h:77
> IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
> IP: [] __mutex_lock_slowpath+0x6f/0x100
> kernel/locking/mutex.c:824
> PGD 1c555067 PUD 1c554067 PMD 0
> Oops: 0002 [#1] SMP
> Modules linked in:
> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88001c40a700 task.stack: 88001c984000
> RIP: 0010:[] []
> __mutex_lock_slowpath+0x6f/0x100
> RSP: 0018:88001c987cb0 EFLAGS: 00010282
> RAX: RBX: 88001d5212a0 RCX: c100
> RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4
> RBP: 88001c987cf8 R08: 88001c984000 R09:
> R10: R11: R12: 88001c40a700
> R13: 88001d5212a4 R14: R15: 88001d5212a8
> FS: 00dc9880() GS:88001f00() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: CR3: 1c8a9000 CR4: 000406f0
> Stack:
> 88001d5212a8 811a398f
> 88001d5212a0 88001d5212a0
> 81a6eb20 88001c987d10 818e85ba 88001d521000
> Call Trace:
> [< inline >] __mutex_fastpath_lock
> ./arch/x86/include/asm/mutex_64.h:28
> [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102
> [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329
> [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360
> [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999
> [] drm_mode_page_flip_ioctl+0x4e/0x300
> drivers/gpu/drm/drm_crtc.c:5414
> [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681
> [] entry_SYSCALL_64_fastpath+0x13/0x8f
> arch/x86/entry/entry_64.S:207
> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c
> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48>
> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04
> RIP [< inline >] __list_add ./include/linux/list.h:44
> RIP [< inline >] list_add_tail ./include/linux/list.h:77
> RIP [< inline >] __mutex_lock_common kernel/locking/mutex.c:543
> RIP [] __mutex_lock_slowpath+0x6f/0x100
> kernel/locking/mutex.c:824
> RSP
> CR2:
> ---[ end trace 3cef4eb618ac6bb6 ]---
> ===
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/dri/card0", 0);
> mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul);
> memcpy((void*)0x20036ad7,
> "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35"
> "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45"
> "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33"
> "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91"
> "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb"
> "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e"
> "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2"
> "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e"
> "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7"
> "\x1c\x17\x03\x60\x7b\x31\x1f\x66",
> 143);
> ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0);
> return 0;
> }
>
> I build the ToT kernel (commit
> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and
> CONFIG_DRM_VGEM=y.
+dri-devel
I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of
linux-next.
drm: GPF in drm_getcap
Hello,
The following program triggers GPF in drm_getcap:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
int fd = open("/dev/dri/card0", O_RDONLY);
uint64_t data[2] = {0x11, 0x80};
ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
return 0;
}
general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 8800310dc540 task.stack: 88003cbc
RIP: 0010:[] []
drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP: 0018:88003cbc7c28 EFLAGS: 00010202
RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
R13: dc00 R14: 88003bcc6850 R15: fff2
FS: 7fcbf4e03700() GS:88003ed0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006dce00 CR3: 66135000 CR4: 06e0
DR0: 001e DR1: 001e DR2:
DR3: DR6: 0ff0 DR7: 0600
Stack:
88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
fff2 88003cbc7dc0 834cb57c e200
1101 875a1ba0 882ae930 0010
Call Trace:
[] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] entry_SYSCALL_64_fastpath+0x23/0xc1
Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
RIP [] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP
---[ end trace c6e1afa8cd73b880 ]---
On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
Re: INFO: trying to register non-static key in try_to_wake_up
On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra wrote: > > On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692 > > dashboard link: https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+e84d7ebd1361da13c...@syzkaller.appspotmail.com > > > > INFO: trying to register non-static key. > > the code is fine but needs lockdep annotation. > > turning off the locking correctness validator. > > CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Call Trace: > > > > __dump_stack lib/dump_stack.c:77 [inline] > > dump_stack+0x188/0x20d lib/dump_stack.c:118 > > assign_lock_key kernel/locking/lockdep.c:880 [inline] > > register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189 > > __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836 > > lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484 > > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] > > _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159 > > try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547 > > That's p->pi_lock, which gets initialized in rt_mutex_init_task() in > copy_process(). This should be impossible. Very odd. The stack mentions fbdev, which is a red flag at the moment. There are a dozen of bad bugs in fbdev and around. Just few days ago Andy pointed to another "impossible" crash "general protection fault in do_syscall_64" which is related to dri: https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9 https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ There are probably more random manifestations of these bugs already, and I guess we will be getting more. +fbdev maintainers > > wake_up_worker kernel/workqueue.c:836 [inline] > > insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337 > > __queue_work+0x50d/0x1280 kernel/workqueue.c:1488 > > call_timer_fn+0x195/0x760 kernel/time/timer.c:1404 > > expire_timers kernel/time/timer.c:1444 [inline] > > __run_timers kernel/time/timer.c:1773 [inline] > > __run_timers kernel/time/timer.c:1740 [inline] > > run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786 > > __do_softirq+0x26c/0x99d kernel/softirq.c:292 > > invoke_softirq kernel/softirq.c:373 [inline] > > irq_exit+0x192/0x1d0 kernel/softirq.c:413 > > exiting_irq arch/x86/include/asm/apic.h:546 [inline] > > smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146 > > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 > > > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/20200331095737.GO20730%40hirez.programming.kicks-ass.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
gpu: kmalloc size WARNING in vga_arb_write
Hello, I've hit the following warning while running syzkaller fuzzer: [ cut here ] WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999 __alloc_pages_nodemask+0x7d2/0x1760() Modules linked in: CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 880069eff670 8299a06d 8800658a4740 864985a0 880069eff6b0 8134fcf9 8166de32 864985a0 0bb7 024040c0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999 [] __alloc_pages_nodemask+0x7d2/0x1760 mm/page_alloc.c:3253 [] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090 [< inline >] alloc_pages include/linux/gfp.h:459 [] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433 [] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008 [] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019 [< inline >] kmalloc_large include/linux/slab.h:395 [] __kmalloc+0x2f4/0x340 mm/slub.c:3557 [< inline >] kmalloc include/linux/slab.h:468 [] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926 [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719 [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849 [] vfs_writev+0x86/0xc0 fs/read_write.c:886 [< inline >] SYSC_writev fs/read_write.c:919 [] SyS_writev+0x111/0x2b0 fs/read_write.c:911 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 ---[ end trace d543527022b589ec ]--- vga_arb_write does: kbuf = kmalloc(count + 1, GFP_KERNEL); The kmalloc should use GFP_USER|__GFP_NOWARN flags since the size is user-controlled. On commit 92e963f50fc74041b5e9e744c330dca48e04f08d.
drm: WARNING in drm_irq_by_busid
Hello, I've got the following WARNING while running syzkaller fuzzer: [ cut here ] WARNING: CPU: 1 PID: 16092 at drivers/gpu/drm/drm_pci.c:182 drm_irq_by_busid+0x3c0/0x4a0 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 16092 Comm: syz-executor Not tainted 4.8.0-rc3+ #33 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 884b8280 880032c07b00 82d1b239 0178 fbfff1097050 86e8eec0 880032c07bd8 873a2c00 dc00 0009 880032c07bc8 816ab4e3 Call Trace: [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:552 [] drm_irq_by_busid+0x3c0/0x4a0 drivers/gpu/drm/drm_pci.c:182 [] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724 [< inline >] vfs_ioctl fs/ioctl.c:43 [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675 [< inline >] SYSC_ioctl fs/ioctl.c:690 [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681 [] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Unfortunately it's not reproducible. Probably fuzzer can't guess the right bus id (there is no simple way to extract correct bus id). But it happens regularly. On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Auh 25).
drm: WARNING in ioremap_wc
Hello,
The following program triggers WARNING in ioremap_wc:
[ cut here ]
LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12061
cmdline="/tmp/syz-executor"
WARNING: CPU: 1 PID: 12056 at arch/x86/mm/ioremap.c:121[< none
>] __ioremap_caller+0x348/0x6b0 arch/x86/mm/ioremap.c:120
LoadPin: kernel-module denied obj="/memfd: (deleted)" pid=12063
cmdline="/tmp/syz-executor"
ioremap on RAM at 0x20068000 - 0x20068fff
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 12056 Comm: syz-executor Not tainted 4.8.0-rc3+ #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
884b8280 8800295777f0 82d1b239 00bd6000
fbfff1097050 86e8eec0 8800295778c8 86e7ad00
dc00 0009 8800295778b8 816ab4e3
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x12e/0x185 lib/dump_stack.c:51
[] panic+0x1e4/0x3ef kernel/panic.c:153
[] __warn+0x1c4/0x1e0 kernel/panic.c:509
[] warn_slowpath_fmt+0xac/0xd0 kernel/panic.c:532
[] __ioremap_caller+0x348/0x6b0 arch/x86/mm/ioremap.c:120
[] ioremap_wc+0x26/0x30 arch/x86/mm/ioremap.c:290
[] drm_addmap_core+0xf1e/0x16c0
drivers/gpu/drm/drm_bufs.c:213
[] drm_legacy_addmap_ioctl+0x1ca/0x340
drivers/gpu/drm/drm_bufs.c:403
[] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
[] entry_SYSCALL64_slow_path+0x25/0x25
arch/x86/entry/entry_64.S:248
On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Aug 25).
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 102
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 101
#endif
#ifndef __NR_ioctl
#define __NR_ioctl 16
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 103
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 104
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...)\
{\
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, "", target, "fuse", flags, buf);
return fd;
}
static uintptr_t syz_fuseblk_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
dri: WARNING in idr_remove
Hello,
The following program causes a WARNING in idr_remove:
[ cut here ]
WARNING: CPU: 3 PID: 26766 at lib/idr.c:505
idr_remove called for id=1 which is not allocated.
CPU: 3 PID: 26766 Comm: syz-executor Not tainted 4.8.0-rc3+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
884b8280 8800634878d8 82d1b239 01fc
fbfff1097050 86e8eec0 8800634879b0 8723b400
dc00 0009 8800634879a0 816ab4e3
Call Trace:
[] warn_slowpath_fmt+0xac/0xd0 kernel/panic.c:532
[< inline >] idr_remove_warning lib/idr.c:505
[] idr_remove+0x617/0x830 lib/idr.c:559
[] drm_legacy_ctxbitmap_free+0x9d/0xd0
drivers/gpu/drm/drm_context.c:61
[] drm_legacy_rmctx+0x30e/0x410
drivers/gpu/drm/drm_context.c:496
[] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] do_syscall_64+0x1df/0x640 arch/x86/entry/common.c:288
[] entry_SYSCALL64_slow_path+0x25/0x25
arch/x86/entry/entry_64.S:248
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
int main()
{
syscall(__NR_mmap, 0x2000ul, 0xc000ul, 0x3ul,
0x32ul, -1, 0x0ul, 0, 0, 0);
int fd = open("/dev/dri/card0", 0x101102ul, 0);
*(uint32_t*)0x2000b000 = (uint32_t)0x2;
*(uint64_t*)0x2000b008 = (uint64_t)0x2000b000;
syscall(__NR_ioctl, fd, 0xc0106426ul, 0x2000b000ul);
int res = *(uint32_t*)0x2000b000;
*(uint32_t*)0x2000bff8 = res;
*(uint32_t*)0x2000bffc = (uint32_t)0x2;
syscall(__NR_ioctl, fd, 0xc0086421ul, 0x2000bff8ul);
return 0;
}
On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Aug 25).
drm: GPF in drm_legacy_lock_free
Hello,
The following program trigger GPF in drm_legacy_lock_free:
general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 2 PID: 3379 Comm: syz-executor Not tainted 4.8.0-rc3+ #35
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 8800637840c0 task.stack: 880063fa8000
RIP: 0010:[]
[] drm_legacy_lock_free+0x2a1/0x3c0
drivers/gpu/drm/drm_lock.c:133
RSP: 0018:880063fafa68 EFLAGS: 00010287
RAX: 8341a781 RBX: 880063fafc20 RCX: c900040e4000
RDX: 0065 RSI: 880063784900 RDI: 884b8298
RBP: 880063fafc48 R08: 0001 R09:
R10: R11: R12: 88006821e580
R13: 0003 R14: R15: dc00
FS: 7f21ada94700() GS:88006d40() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2000aff8 CR3: 3bcc4000 CR4: 06e0
Stack:
0001004af988 11000c7f5f50 88006821e5e0 41b58ab3
88116d28 8341a4e0 89e748d0 8a3b4e60
8800637848f0 880063784918 880063784920 8800637848f8
Call Trace:
[] drm_legacy_unlock+0xda/0x170
drivers/gpu/drm/drm_lock.c:264
[] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
Code: ff ff 4d 89 f7 4d 89 f5 49 c1 ef 03 41 83 e5 07 41 83 c5 03 e8
61 a0 80 03 48 b8 00 00 00 00 00 fc ff df 49 01 c7 e8 5f 52 19 fe <41>
0f b6 07 41 38 c5 7c 08 84 c0 0f 85 f4 00 00 00 41 8b 3e 89
RIP [] drm_legacy_lock_free+0x2a1/0x3c0
drivers/gpu/drm/drm_lock.c:133
RSP
---[ end trace 0b3780f72376546b ]---
Kernel panic - not syncing: Fatal exception
On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Aug 25)
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 101
#endif
#ifndef __NR_ioctl
#define __NR_ioctl 16
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 103
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 104
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 102
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...)\
{\
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
drm: GPF in drm_context_switch_complete
Hello,
The following program triggers GPF in drm_context_switch_complete:
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 1965 Comm: syz-executor Not tainted 4.8.0-rc3+ #33
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88003c87a480 task.stack: 88002e54
RIP: 0010:[]
[< inline >] drm_context_switch_complete
drivers/gpu/drm/drm_context.c:303
[] drm_legacy_newctx+0x190/0x290
drivers/gpu/drm/drm_context.c:467
RSP: 0018:88002e547c50 EFLAGS: 00010246
RAX: dc00 RBX: 88006af6 RCX: c9000178
RDX: RSI: 88002e547cf8 RDI: 88003d15b640
RBP: 88002e547c70 R08: R09:
R10: R11: R12:
R13: 880032b6f6c0 R14: R15:
FS: 7f14ed4f2700() GS:88003ed0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2000a000 CR3: 38762000 CR4: 06e0
Stack:
88002e547cf8 88006af6 8739efd8 88ae13c0
88002e547dc0 83410a5c 8800 8739efdc
83408b10 880032b6f6e8 2000a000 88002e547cf8
Call Trace:
[] drm_ioctl+0x7bc/0xc60 drivers/gpu/drm/drm_ioctl.c:724
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
Code: 00 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 02 01 00 00 4d 8b a4
24 80 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <0f>
b6 14 02 4c 89 e0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP [< inline >] drm_context_switch_complete
drivers/gpu/drm/drm_context.c:303
RIP [] drm_legacy_newctx+0x190/0x290
drivers/gpu/drm/drm_context.c:467
RSP
---[ end trace f61dcca66bdbbe88 ]---
On commit 61c04572de404e52a655a36752e696bbcb483cf5 (Aug 25).
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_ioctl
#define __NR_ioctl 16
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 103
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 104
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 102
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 101
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...)\
{\
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
i
[PATCH] drivers/gpu/vga: use __GFP_NOWARN for user-controlled kmalloc
Size of kmalloc() in vga_arb_write() is controlled by user. Too large kmalloc() size triggers WARNING message on console. Use GFP_USER | __GFP_NOWARN for this kmalloc() to not scare admins. Signed-off-by: Dmitry Vyukov --- Example WARNING: WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999 __alloc_pages_nodemask+0x7d2/0x1760() Modules linked in: CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 880069eff670 8299a06d 8800658a4740 864985a0 880069eff6b0 8134fcf9 8166de32 864985a0 0bb7 024040c0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999 [] __alloc_pages_nodemask+0x7d2/0x1760 mm/page_alloc.c:3253 [] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090 [< inline >] alloc_pages include/linux/gfp.h:459 [] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433 [] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008 [] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019 [< inline >] kmalloc_large include/linux/slab.h:395 [] __kmalloc+0x2f4/0x340 mm/slub.c:3557 [< inline >] kmalloc include/linux/slab.h:468 [] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926 [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719 [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849 [] vfs_writev+0x86/0xc0 fs/read_write.c:886 [< inline >] SYSC_writev fs/read_write.c:919 [] SyS_writev+0x111/0x2b0 fs/read_write.c:911 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 --- drivers/gpu/vga/vgaarb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index f17cb04..d73b85b 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -923,7 +923,7 @@ static ssize_t vga_arb_write(struct file *file, const char __user *buf, int i; - kbuf = kmalloc(count + 1, GFP_KERNEL); + kbuf = kmalloc(count + 1, GFP_USER | __GFP_NOWARN); if (!kbuf) return -ENOMEM; -- 2.7.0.rc3.207.g0ac5344
[PATCH] drivers/gpu/vga: use __GFP_NOWARN for user-controlled kmalloc
On Thu, Feb 4, 2016 at 5:59 PM, Ville Syrjälä wrote: > On Thu, Feb 04, 2016 at 05:37:49PM +0100, Dmitry Vyukov wrote: >> On Thu, Feb 4, 2016 at 5:32 PM, Ville Syrjälä >> wrote: >> > On Thu, Feb 04, 2016 at 04:49:49PM +0100, Dmitry Vyukov wrote: >> >> Size of kmalloc() in vga_arb_write() is controlled by user. >> >> Too large kmalloc() size triggers WARNING message on console. >> >> >> >> Use GFP_USER | __GFP_NOWARN for this kmalloc() to not scare admins. >> >> >> >> Signed-off-by: Dmitry Vyukov >> >> --- >> >> Example WARNING: >> >> >> >> WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999 >> >> __alloc_pages_nodemask+0x7d2/0x1760() >> >> Modules linked in: >> >> CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283 >> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs >> >> 01/01/2011 >> >> 880069eff670 8299a06d >> >> 8800658a4740 864985a0 880069eff6b0 8134fcf9 >> >> 8166de32 864985a0 0bb7 024040c0 >> >> Call Trace: >> >> [< inline >] __dump_stack lib/dump_stack.c:15 >> >> [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 >> >> [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 >> >> [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 >> >> [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999 >> >> [] __alloc_pages_nodemask+0x7d2/0x1760 >> >> mm/page_alloc.c:3253 >> >> [] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090 >> >> [< inline >] alloc_pages include/linux/gfp.h:459 >> >> [] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433 >> >> [] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008 >> >> [] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019 >> >> [< inline >] kmalloc_large include/linux/slab.h:395 >> >> [] __kmalloc+0x2f4/0x340 mm/slub.c:3557 >> >> [< inline >] kmalloc include/linux/slab.h:468 >> >> [] vga_arb_write+0xd4/0xe40 >> >> drivers/gpu/vga/vgaarb.c:926 >> >> [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719 >> >> [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849 >> >> [] vfs_writev+0x86/0xc0 fs/read_write.c:886 >> >> [< inline >] SYSC_writev fs/read_write.c:919 >> >> [] SyS_writev+0x111/0x2b0 fs/read_write.c:911 >> >> [] entry_SYSCALL_64_fastpath+0x16/0x7a >> >> arch/x86/entry/entry_64.S:185 >> >> --- >> >> drivers/gpu/vga/vgaarb.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c >> >> index f17cb04..d73b85b 100644 >> >> --- a/drivers/gpu/vga/vgaarb.c >> >> +++ b/drivers/gpu/vga/vgaarb.c >> >> @@ -923,7 +923,7 @@ static ssize_t vga_arb_write(struct file *file, const >> >> char __user *buf, >> >> int i; >> >> >> >> >> >> - kbuf = kmalloc(count + 1, GFP_KERNEL); >> >> + kbuf = kmalloc(count + 1, GFP_USER | __GFP_NOWARN); >> > >> > I don't really see why it does this user controlled malloc in the >> > first place. The max legth of the string it will actually handle looks >> > well bounded, so it could just use some fixed length buffer (on stack >> > even). >> >> >> What would be the right limit on data len? > > From the looks of things the longest command could be the > "target PCI:domain:bus:dev.fn" thing. Even assuming something silly like > having 10 characters for each domain,bus,dev,fn that would still be only > 55 bytes. So based on that even something like 64 bytes should be more > than enough AFAICS. David, what do you think? I can allocate char kbuf[64] on stack. > The other thing that strikes me as bit odd in this code is that it > just ignores whatever data is left over after it's done parsing the > string. But it returns the full count to userspace, indicating it > ate all of it. I guess that's fairly sane when userspace just uses a > fixed size buffer and checks that the kernel consumed it all. But > maybe there should be an actual check to see that there's a '\0' > or maybe +'\0' after the parsed string.
[PATCH] drivers/gpu/vga: use __GFP_NOWARN for user-controlled kmalloc
On Thu, Feb 4, 2016 at 5:32 PM, Ville Syrjälä wrote: > On Thu, Feb 04, 2016 at 04:49:49PM +0100, Dmitry Vyukov wrote: >> Size of kmalloc() in vga_arb_write() is controlled by user. >> Too large kmalloc() size triggers WARNING message on console. >> >> Use GFP_USER | __GFP_NOWARN for this kmalloc() to not scare admins. >> >> Signed-off-by: Dmitry Vyukov >> --- >> Example WARNING: >> >> WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999 >> __alloc_pages_nodemask+0x7d2/0x1760() >> Modules linked in: >> CPU: 2 PID: 29322 Comm: syz-executor Tainted: GB 4.5.0-rc1+ #283 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> 880069eff670 8299a06d >> 8800658a4740 864985a0 880069eff6b0 8134fcf9 >> 8166de32 864985a0 0bb7 024040c0 >> Call Trace: >> [< inline >] __dump_stack lib/dump_stack.c:15 >> [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 >> [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 >> [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 >> [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999 >> [] __alloc_pages_nodemask+0x7d2/0x1760 >> mm/page_alloc.c:3253 >> [] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090 >> [< inline >] alloc_pages include/linux/gfp.h:459 >> [] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433 >> [] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008 >> [] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019 >> [< inline >] kmalloc_large include/linux/slab.h:395 >> [] __kmalloc+0x2f4/0x340 mm/slub.c:3557 >> [< inline >] kmalloc include/linux/slab.h:468 >> [] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926 >> [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719 >> [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849 >> [] vfs_writev+0x86/0xc0 fs/read_write.c:886 >> [< inline >] SYSC_writev fs/read_write.c:919 >> [] SyS_writev+0x111/0x2b0 fs/read_write.c:911 >> [] entry_SYSCALL_64_fastpath+0x16/0x7a >> arch/x86/entry/entry_64.S:185 >> --- >> drivers/gpu/vga/vgaarb.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c >> index f17cb04..d73b85b 100644 >> --- a/drivers/gpu/vga/vgaarb.c >> +++ b/drivers/gpu/vga/vgaarb.c >> @@ -923,7 +923,7 @@ static ssize_t vga_arb_write(struct file *file, const >> char __user *buf, >> int i; >> >> >> - kbuf = kmalloc(count + 1, GFP_KERNEL); >> + kbuf = kmalloc(count + 1, GFP_USER | __GFP_NOWARN); > > I don't really see why it does this user controlled malloc in the > first place. The max legth of the string it will actually handle looks > well bounded, so it could just use some fixed length buffer (on stack > even). What would be the right limit on data len?
Re: KASAN: use-after-free Read in drm_gem_object_release
On Thu, Oct 25, 2018 at 9:18 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:bd6bf7c10484 Merge tag 'pci-v4.20-changes' of git://git.ke.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1448a68340 > kernel config: https://syzkaller.appspot.com/x/.config?x=2dd8629d56664133 > dashboard link: https://syzkaller.appspot.com/bug?extid=e73f2fb5ed5a5df36d33 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11331de540 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1334e64d40 +drm maintainers > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+e73f2fb5ed5a5df36...@syzkaller.appspotmail.com > > drm_mode_create_dumb+0x28d/0x310 drivers/gpu/drm/drm_dumb_buffers.c:92 > drm_mode_create_dumb_ioctl+0x25/0x30 drivers/gpu/drm/drm_dumb_buffers.c:98 > drm_ioctl_kernel+0x245/0x2f0 drivers/gpu/drm/drm_ioctl.c:751 > drm_ioctl+0x57a/0xb20 drivers/gpu/drm/drm_ioctl.c:847 > == > BUG: KASAN: use-after-free in drm_gem_object_release+0xf1/0x110 > drivers/gpu/drm/drm_gem.c:813 > Read of size 8 at addr 8801d83d3410 by task syz-executor977/6742 > > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x445989 > Code: e8 4c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff > 0f 83 6b c8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7ffcf076f4e8 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffcf076f500 RCX: 00445989 > RDX: 2000 RSI: ffb2 RDI: 0003 > RBP: 0004 R08: 0001 R09: 0100 > R10: R11: 0246 R12: > R13: R14: R15: > CPU: 0 PID: 6742 Comm: syz-executor977 Not tainted 4.19.0+ #80 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x244/0x39d lib/dump_stack.c:113 > print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256 > kasan_report_error mm/kasan/report.c:354 [inline] > kasan_report.cold.8+0x242/0x309 mm/kasan/report.c:412 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 > drm_gem_object_release+0xf1/0x110 drivers/gpu/drm/drm_gem.c:813 > __vgem_gem_destroy drivers/gpu/drm/vgem/vgem_drv.c:175 [inline] > vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:199 [inline] > vgem_gem_dumb_create+0x1f8/0x260 drivers/gpu/drm/vgem/vgem_drv.c:214 > drm_mode_create_dumb+0x28d/0x310 drivers/gpu/drm/drm_dumb_buffers.c:92 > drm_mode_create_dumb_ioctl+0x25/0x30 drivers/gpu/drm/drm_dumb_buffers.c:98 > drm_ioctl_kernel+0x245/0x2f0 drivers/gpu/drm/drm_ioctl.c:751 > drm_ioctl+0x57a/0xb20 drivers/gpu/drm/drm_ioctl.c:847 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x445989 > Code: e8 4c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff > 0f 83 6b c8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7ffcf076f4e8 EFLAGS: 0246 ORIG_RAX: 0010 > RAX: ffda RBX: 7ffcf076f500 RCX: 00445989 > RDX: 2000 RSI: ffb2 RDI: 0003 > RBP: 0004 R08: 0001 R09: 0100 > R10: R11: 0246 R12: > R13: R14: R15: > > Allocated by task 6742: > save_stack+0x43/0xd0 mm/kasan/kasan.c:448 > set_track mm/kasan/kasan.c:460 [inline] > kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553 > kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620 > kmalloc include/linux/slab.h:513 [inline] > kzalloc include/linux/slab.h:707 [inline] > __vgem_gem_create+0x4c/0x100 drivers/gpu/drm/vgem/vgem_drv.c:158 > vgem_gem_create drivers/gpu/drm/vgem/vgem_drv.c:187 [inline] > vgem_gem_dumb_create+0xce/0x260 drivers/gpu/drm/vgem/vgem_drv.c:214 > drm_mode_create_dumb+0x28d/0x310 drivers/gpu/drm/drm_dumb_
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote: > On 08/01/2018 02:03 AM, Andrey Ryabinin wrote: > >> I can't think of any advantage in not having the constructor. > > I can't see any advantage adding another indirect call, > in RETPOLINE world. Can you please elaborate what's the problem here? If slab ctor call have RETPOLINE, then using ctors more does not introduce any security problems and they are not _that_ slow. If slab ctors are not protected, then we have problem that needs to be fixed already. What am I missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Tue, Jul 31, 2018 at 7:41 PM, Eric Dumazet wrote: > On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote: > >> >> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU? > > To allow fast reuse of objects, without going through call_rcu() and > reducing cache efficiency. > > I believe this is mentioned in Documentation/RCU/rculist_nulls.txt Is it OK to overwrite ct->status? It seems that are some read and writes to it right after atomic_inc_not_zero. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 10:46 AM, Dmitry Vyukov wrote:
> On Tue, Jul 31, 2018 at 8:51 PM, Linus Torvalds
> wrote:
>> On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
>> wrote:
>>>
>>> So the re-use might initialize the fields lazily, not necessarily using a
>>> ctor.
>>
>> In particular, the pattern that nf_conntrack uses looks like it is safe.
>>
>> If you have a well-defined refcount, and use "atomic_inc_not_zero()"
>> to guard the speculative RCU access section, and use
>> "atomic_dec_and_test()" in the freeing section, then you should be
>> safe wrt new allocations.
>>
>> If you have a completely new allocation that has "random stale
>> content", you know that it cannot be on the RCU list, so there is no
>> speculative access that can ever see that random content.
>>
>> So the only case you need to worry about is a re-use allocation, and
>> you know that the refcount will start out as zero even if you don't
>> have a constructor.
>>
>> So you can think of the refcount itself as always having a zero
>> constructor, *BUT* you need to be careful with ordering.
>>
>> In particular, whoever does the allocation needs to then set the
>> refcount to a non-zero value *after* it has initialized all the other
>> fields. And in particular, it needs to make sure that it uses the
>> proper memory ordering to do so.
>>
>> And in this case, we have
>>
>> static struct nf_conn *
>> __nf_conntrack_alloc(struct net *net,
>> {
>> ...
>> atomic_set(&ct->ct_general.use, 0);
>>
>> which is a no-op for the re-use case (whether racing or not, since any
>> "inc_not_zero" users won't touch it), but initializes it to zero for
>> the "completely new object" case.
>>
>> And then, the thing that actually exposes it to the speculative walkers does:
>>
>> int
>> nf_conntrack_hash_check_insert(struct nf_conn *ct)
>> {
>> ...
>> smp_wmb();
>> /* The caller holds a reference to this object */
>> atomic_set(&ct->ct_general.use, 2);
>>
>> which means that it stays as zero until everything is actually set up,
>> and then the optimistic walker can use the other fields (including
>> spinlocks etc) to verify that it's actually the right thing. The
>> smp_wmb() means that the previous initialization really will be
>> visible before the object is visible.
>>
>> Side note: on some architectures it might help to make that "smp_wmb
>> -> atomic_set()" sequence be am "smp_store_release()" instead. Doesn't
>> matter on x86, but might matter on arm64.
>>
>> NOTE! One thing to be very worried about is that re-initializing
>> whatever RCU lists means that now the RCU walker may be walking on the
>> wrong list so the walker may do the right thing for this particular
>> entry, but it may miss walking *other* entries. So then you can get
>> spurious lookup failures, because the RCU walker never walked all the
>> way to the end of the right list. That ends up being a much more
>> subtle bug.
>>
>> But the nf_conntrack case seems to get that right too, see the restart
>> in nf_conntrack_find().
>>
>> So I don't see anything wrong in nf_conntrack.
>>
>> But yes, using SLAB_TYPESAFE_BY_RCU is very very subtle. But most of
>> the subtleties have nothing to do with having a constructor, they are
>> about those "make sure memory ordering wrt refcount is right" and
>> "restart speculative RCU walk" issues that actually happen regardless
>> of having a constructor or not.
>
>
> Thank you, this is very enlightening.
>
> So the type-stable invariant is established by initialization of the
> object after the first kmem_cache_alloc, and then we rely on the fact
> that repeated initialization does not break the invariant, which works
> because the state is very simple (including debug builds, i.e. no
> ODEBUG nor magic values).
Still can't grasp all details.
There is state that we read without taking ct->ct_general.use ref
first, namely ct->state and what's used by nf_ct_key_equal.
So let's say the entry we want to find is in the list, but
nf_conntrack_find finds a wrong entry earlier because all state it
looks at is random garbage, so it returns the wrong entry to
__nf_conntrack_find_get.
Now (nf_ct_is_dying(ct) || !atomic_inc_not_zero(&ct->ct_general.use))
check in __nf_conntrack_find_get passes, and it returns NULL to the
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 5:37 PM, Eric Dumazet wrote: > On Wed, Aug 1, 2018 at 8:15 AM Christopher Lameter wrote: >> >> On Wed, 1 Aug 2018, Dmitry Vyukov wrote: >> >> > But we are trading 1 indirect call for comparable overhead removed >> > from much more common path. The path that does ctors is also calling >> > into page alloc, which is much more expensive. >> > So ctor should be a net win on performance front, no? >> >> ctor would make it esier to review the flow and guarantee that the object >> always has certain fields set as required before any use by the subsystem. >> >> ctors are run once on allocation of the slab page for all objects in it. >> >> ctors are not called duiring allocation and freeing of objects from the >> slab page. So we could avoid the intialization of the spinlock on each >> object allocation which actually should be faster. > > > This strategy might have been a win 30 years ago when cpu had no > caches (or too small anyway) > > What probability is that the 60 bytes around the spinlock are not > touched after the object is freshly allocated ? > > -> None > > Writing 60 bytes in one cache line instead of 64 has really the same > cost. The cache line miss is the real killer. > > Feel free to write the patches, test them, but I doubt you will have any > gain. > > Remember btw that TCP sockets can be either completely fresh > (socket() call, using memset() to clear the whole object), > or clones (accept() thus copying the parent socket) > > The idea of having a ctor() would only be a win if all the fields that > can be initialized in the ctor are contiguous and fill an integral > number of cache lines. Code size can have some visible performance impact too. But either way, what you say only means that ctors are not necessary significantly faster. But your original point was that they are slower. If they are not slower, then what Andrey said seems to make sense: some gain on code comprehension front re type-stability invariant + some gain on performance front (even if not too big) and no downsides. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote:
> Dmitry Vyukov wrote:
>> Still can't grasp all details.
>> There is state that we read without taking ct->ct_general.use ref
>> first, namely ct->state and what's used by nf_ct_key_equal.
>> So let's say the entry we want to find is in the list, but
>> nf_conntrack_find finds a wrong entry earlier because all state it
>> looks at is random garbage, so it returns the wrong entry to
>> __nf_conntrack_find_get.
>
> If an entry can be found, it can't be random garbage.
> We never link entries into global table until state has been set up.
But... we don't hold a reference to the entry. So say it's in the
table with valid state, now nf_conntrack_find discovers it, now
the entry is removed and reused a dozen of times will all associated
state reinitialization. And nf_ct_key_equal looks at it concurrently
and decides if it's the entry we are looking for or now. I think
unless we hold a ref to the entry, it's state needs to be considered
random garbage for correctness reasoning.
>> Now (nf_ct_is_dying(ct) || !atomic_inc_not_zero(&ct->ct_general.use))
>> check in __nf_conntrack_find_get passes, and it returns NULL to the
>> caller (which means entry is not present).
>
> So entry is going away or marked as dead which for us is same as
> 'not present', we need to allocate a new entry.
>
>> While in reality the entry
>> is present, but we were just looking at the wrong one.
>
> We never add tuples that are identical to the global table.
>
> If N cores receive identical packets at same time with no prior state, all
> will allocate a new conntrack, but we notice this when we try to insert the
> nf_conn entries into the table.
>
> Only one will succeed, other cpus have to cope with this.
> (worst case: all raced packets are dropped along with their conntrack
> object).
>
> For lookup, we have following scenarios:
>
> 1. It doesn't exist -> new allocation needed
> 2. It exists, not dead, has nonzero refount -> use it
> 3. It exists, but marked as dying -> new allocation needed
> 4. It exists but has 0 reference count -> new allocation needed
> 5. It exists, we get reference, but 2nd nf_ct_key_equal check
>fails. We saw a matching 'old incarnation' that just got
>re-used on other core. -> retry lookup
>
>> Also I am not sure about order of checks in (nf_ct_is_dying(ct) ||
>> !atomic_inc_not_zero(&ct->ct_general.use)), because checking state
>> before taking the ref is only a best-effort hint, so it can actually
>> be a dying entry when we take a ref.
>
> Yes, it can also become a dying entry after we took the reference.
>
>> So shouldn't it read something like the following?
>>
>> rcu_read_lock();
>> begin:
>> h = nf_conntrack_find(net, zone, tuple, hash);
>> if (h) {
>> ct = nf_ct_tuplehash_to_ctrack(h);
>> if (!atomic_inc_not_zero(&ct->ct_general.use))
>> goto begin;
>> if (unlikely(nf_ct_is_dying(ct)) ||
>> unlikely(!nf_ct_key_equal(h, tuple, zone, net))) {
>> nf_ct_put(ct);
>
> It would be ok to make this change, but dying bit can be set
> at any time e.g. because userspace tells kernel to flush the conntrack table.
> So refcount is always > 0 when the DYING bit is set.
>
> I don't see why it would be a problem.
>
> nf_conn struct will stay valid until all cpus have dropped references.
> The check in lookup function only serves to hide the known-to-go-away entry.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 1:28 PM, Eric Dumazet wrote: > On 08/01/2018 03:34 AM, Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote: >>> On 08/01/2018 02:03 AM, Andrey Ryabinin wrote: >>> >>>> I can't think of any advantage in not having the constructor. >>> >>> I can't see any advantage adding another indirect call, >>> in RETPOLINE world. >> >> Can you please elaborate what's the problem here? >> If slab ctor call have RETPOLINE, then using ctors more does not >> introduce any security problems and they are not _that_ slow. > > They _are_ slow, when we have dozens of them in a code path. > > I object "having to add" yet another indirect call, if this can be avoided [*] > > If some people want to use ctor, fine, but do not request this. > > [*] This can be tricky, but worth the pain. But we are trading 1 indirect call for comparable overhead removed from much more common path. The path that does ctors is also calling into page alloc, which is much more expensive. So ctor should be a net win on performance front, no? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 3:46 PM, Florian Westphal wrote: > Dmitry Vyukov wrote: >> If that scenario is possible that a fix would be to make > > Looks possible. > >> __nf_conntrack_find_get ever return NULL iff it got NULL from >> nf_conntrack_find (not if any of the checks has failed). > > I don't see why we need to restart on nf_ct_is_dying(), but other > than that this seems ok. Because it can be a wrong entry dying. When we check dying, we don't yet know if we are looking at the right entry or not. If we successfully acquire a reference, then recheck nf_ct_key_equal and _then_ check dying, then we don't need to restart on dying. But with the current check order, we need to restart on dying too. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 6:25 PM, Eric Dumazet wrote: > On 08/01/2018 09:22 AM, Christopher Lameter wrote: >> On Wed, 1 Aug 2018, Eric Dumazet wrote: >> >>> The idea of having a ctor() would only be a win if all the fields that >>> can be initialized in the ctor are contiguous and fill an integral >>> number of cache lines. >> >> Ok. Its reducing code size and makes the object status more consistent. >> Isn't that enough? >> > > Prove it ;) > > I yet have to seen actual numbers. Proving with numbers is required for a claimed performance improvement at the cost of code degradation/increase. For a win-win change there is really nothing to prove. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Tue, Jul 31, 2018 at 8:51 PM, Linus Torvalds
wrote:
> On Tue, Jul 31, 2018 at 10:49 AM Linus Torvalds
> wrote:
>>
>> So the re-use might initialize the fields lazily, not necessarily using a
>> ctor.
>
> In particular, the pattern that nf_conntrack uses looks like it is safe.
>
> If you have a well-defined refcount, and use "atomic_inc_not_zero()"
> to guard the speculative RCU access section, and use
> "atomic_dec_and_test()" in the freeing section, then you should be
> safe wrt new allocations.
>
> If you have a completely new allocation that has "random stale
> content", you know that it cannot be on the RCU list, so there is no
> speculative access that can ever see that random content.
>
> So the only case you need to worry about is a re-use allocation, and
> you know that the refcount will start out as zero even if you don't
> have a constructor.
>
> So you can think of the refcount itself as always having a zero
> constructor, *BUT* you need to be careful with ordering.
>
> In particular, whoever does the allocation needs to then set the
> refcount to a non-zero value *after* it has initialized all the other
> fields. And in particular, it needs to make sure that it uses the
> proper memory ordering to do so.
>
> And in this case, we have
>
> static struct nf_conn *
> __nf_conntrack_alloc(struct net *net,
> {
> ...
> atomic_set(&ct->ct_general.use, 0);
>
> which is a no-op for the re-use case (whether racing or not, since any
> "inc_not_zero" users won't touch it), but initializes it to zero for
> the "completely new object" case.
>
> And then, the thing that actually exposes it to the speculative walkers does:
>
> int
> nf_conntrack_hash_check_insert(struct nf_conn *ct)
> {
> ...
> smp_wmb();
> /* The caller holds a reference to this object */
> atomic_set(&ct->ct_general.use, 2);
>
> which means that it stays as zero until everything is actually set up,
> and then the optimistic walker can use the other fields (including
> spinlocks etc) to verify that it's actually the right thing. The
> smp_wmb() means that the previous initialization really will be
> visible before the object is visible.
>
> Side note: on some architectures it might help to make that "smp_wmb
> -> atomic_set()" sequence be am "smp_store_release()" instead. Doesn't
> matter on x86, but might matter on arm64.
>
> NOTE! One thing to be very worried about is that re-initializing
> whatever RCU lists means that now the RCU walker may be walking on the
> wrong list so the walker may do the right thing for this particular
> entry, but it may miss walking *other* entries. So then you can get
> spurious lookup failures, because the RCU walker never walked all the
> way to the end of the right list. That ends up being a much more
> subtle bug.
>
> But the nf_conntrack case seems to get that right too, see the restart
> in nf_conntrack_find().
>
> So I don't see anything wrong in nf_conntrack.
>
> But yes, using SLAB_TYPESAFE_BY_RCU is very very subtle. But most of
> the subtleties have nothing to do with having a constructor, they are
> about those "make sure memory ordering wrt refcount is right" and
> "restart speculative RCU walk" issues that actually happen regardless
> of having a constructor or not.
Thank you, this is very enlightening.
So the type-stable invariant is established by initialization of the
object after the first kmem_cache_alloc, and then we rely on the fact
that repeated initialization does not break the invariant, which works
because the state is very simple (including debug builds, i.e. no
ODEBUG nor magic values).
There is a bunch of other SLAB_TYPESAFE_BY_RCU uses without ctor:
https://elixir.bootlin.com/linux/latest/source/fs/jbd2/journal.c#L2395
https://elixir.bootlin.com/linux/latest/source/fs/kernfs/mount.c#L415
https://elixir.bootlin.com/linux/latest/source/net/netfilter/nf_conntrack_core.c#L2065
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/i915_gem.c#L5501
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/selftests/mock_gem_device.c#L212
https://elixir.bootlin.com/linux/latest/source/drivers/staging/lustre/lustre/ldlm/ldlm_lockd.c#L1131
Also these in proto structs:
https://elixir.bootlin.com/linux/latest/source/net/dccp/ipv4.c#L959
https://elixir.bootlin.com/linux/latest/source/net/dccp/ipv6.c#L1048
https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_ipv4.c#L2461
https://elixir.bootlin.com/linux/latest/source/net/ipv6/tcp_ipv6.c#L1980
https://elixir.bootlin.com/linux/latest/source/net/llc/af_llc.c#L145
https://elixir.bootlin.com/linux/latest/source/net/smc/af_smc.c#L105
They later created in net/core/sock.c without ctor.
I guess it would be useful to have such extensive comment for each
SLAB_TYPESAFE_BY_RCU use explaining why it is needed and how all the
tricky aspects are handled.
For example, the one in jbd2 is interesting because it memsets the
whole object before freeing it int
Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
On Wed, Aug 1, 2018 at 1:40 PM, Florian Westphal wrote: > Dmitry Vyukov wrote: >> On Wed, Aug 1, 2018 at 12:35 PM, Florian Westphal wrote: >> > Dmitry Vyukov wrote: >> >> Still can't grasp all details. >> >> There is state that we read without taking ct->ct_general.use ref >> >> first, namely ct->state and what's used by nf_ct_key_equal. >> >> So let's say the entry we want to find is in the list, but >> >> nf_conntrack_find finds a wrong entry earlier because all state it >> >> looks at is random garbage, so it returns the wrong entry to >> >> __nf_conntrack_find_get. >> > >> > If an entry can be found, it can't be random garbage. >> > We never link entries into global table until state has been set up. >> >> But... we don't hold a reference to the entry. So say it's in the >> table with valid state, now nf_conntrack_find discovers it, now >> the entry is removed and reused a dozen of times will all associated >> state reinitialization. And nf_ct_key_equal looks at it concurrently >> and decides if it's the entry we are looking for or now. I think >> unless we hold a ref to the entry, it's state needs to be considered >> random garbage for correctness reasoning. > > It checks if it might be the entry we're looking for. > > If this was complete random garbage, scheme would not work, as then > we could have entry that isn't in table, has nonzero refcount, but > has its confirmed bit set. > > I don't see how that would be possible, any reallocation > makes sure ct->status has CONFIRMED bit clear before setting refcount > to nonzero value. > > I think this is the scenario you hint at is: > 1. nf_ct_key_equal is true > 2. the entry is free'd (or was already free'd) > 3. we return NULL to caller due to atomic_inc_not_zero() failure > > but i fail to see how thats wrong? > > Sure, we could restart lookup but how would that help? > > We'd not find the 'candidate' entry again. > > We might find entry that has been inserted at this very instant but > newly allocated entries are only inserted into global table until the skb that > created the nf_conn object has made it through the network stack > (postrouting for fowarded, or input for local delivery). > > So, the likelyhood of such restart finding another candidate is close to 0, > and won't prevent 'insert race' from happening. The scenario I have in mind is different and it relates to the fact that nf_conntrack_find will return the right entry if it's present, but it can also return an unrelated entry because when it looks at entries they change underneath. Let's take any 2 fields compared by nf_ct_key_equal for simplicity, for example, src.u3 and dst.u3. Let's say we are looking for an entry with src.u3=A and dst.u3=B, let's call it (A,B). Let's say there is an existing entry 1 (A,B) in the global list. But there is also entry 2 (A,C) earlier in the list. Now, nf_conntrack_find starts checking entry 2 (A,C), it checks that src.u3==A, so so far it looks good. Now another thread deletes, reuses and reinitilizes entry 2 for (C,B). Now, nf_conntrack_find checks that dst.u3==B, so it concludes that it's the right entry, because it observed (A,B). Entry 2 is returned to __nf_conntrack_find_get. Now another thread marks entry 2 as dying. Now __nf_conntrack_find_get sees that it's dying and returns NULL to caller, _but_ the matching entry 1 (A,B) was in the list all that time and we should have been discovered it, but we didn't because we were deraield by the wrong entry 2. If that scenario is possible that a fix would be to make __nf_conntrack_find_get ever return NULL iff it got NULL from nf_conntrack_find (not if any of the checks has failed). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_modeset_lock_all
On Tue, Oct 31, 2017 at 3:45 PM, Chris Wilson wrote: > Quoting syzbot (2017-10-27 09:09:50) >> This bug is generated by a dumb bot. It may contain errors. >> See https://goo.gl/tpsmEJ for details. >> Direct all questions to syzkal...@googlegroups.com. >> >> syzbot will keep track of this bug report. >> Once a fix for this bug is committed, please reply to this email with: >> #syz fix: exact-commit-title >> To mark this as a duplicate of another syzbot report, please reply with: >> #syz dup: exact-subject-of-another-report >> If it's a one-off invalid bug report, please reply with: >> #syz invalid >> Note: if the crash happens again, it will cause creation of a new bug >> report. > > Can we use > > Reported-by: syzbot > > > as a unique tag for tracking purposes? Hi, Seems to be a common question. I've added the following to bug template: Please credit me with: Reported-by: syzbot will now be present on newly reported bugs: https://groups.google.com/forum/#!topic/syzkaller-bugs/XE8YSiSZDdA > -Chris > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/150945394709.15081.7550043352916368752%40mail.alporthouse.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_modeset_lock_all
On Tue, Oct 31, 2017 at 2:03 PM, Dmitry Vyukov wrote: > On Tue, Oct 31, 2017 at 3:45 PM, Chris Wilson > wrote: >> Quoting syzbot (2017-10-27 09:09:50) >>> This bug is generated by a dumb bot. It may contain errors. >>> See https://goo.gl/tpsmEJ for details. >>> Direct all questions to syzkal...@googlegroups.com. >>> >>> syzbot will keep track of this bug report. >>> Once a fix for this bug is committed, please reply to this email with: >>> #syz fix: exact-commit-title >>> To mark this as a duplicate of another syzbot report, please reply with: >>> #syz dup: exact-subject-of-another-report >>> If it's a one-off invalid bug report, please reply with: >>> #syz invalid >>> Note: if the crash happens again, it will cause creation of a new bug >>> report. >> >> Can we use >> >> Reported-by: syzbot >> >> >> as a unique tag for tracking purposes? > > > Hi, > > Seems to be a common question. I've added the following to bug template: > > Please credit me with: Reported-by: syzbot > > will now be present on newly reported bugs: > > https://groups.google.com/forum/#!topic/syzkaller-bugs/XE8YSiSZDdA This was fixed by: #syz fix: drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all Now we indeed can use: Reported-by: syzbot which avoids the need to go back and manually attach fixing commit to the report like this. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: d17a1d97dc ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow"): BUG: KASAN: use-after-scope in __drm_mm_interval_first
On Wed, Nov 29, 2017 at 6:21 AM, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit d17a1d97dc208d664c91cc387ffb752c7f85dc61 > Author: Andrey Ryabinin > AuthorDate: Wed Nov 15 17:36:35 2017 -0800 > Commit: Linus Torvalds > CommitDate: Wed Nov 15 18:21:05 2017 -0800 > > x86/mm/kasan: don't use vmemmap_populate() to initialize shadow > > The kasan shadow is currently mapped using vmemmap_populate() since that > provides a semi-convenient way to map pages into init_top_pgt. However, > since that no longer zeroes the mapped pages, it is not suitable for > kasan, which requires zeroed shadow memory. > > Add kasan_populate_shadow() interface and use it instead of > vmemmap_populate(). Besides, this allows us to take advantage of > gigantic pages and use them to populate the shadow, which should save us > some memory wasted on page tables and reduce TLB pressure. > > Link: > http://lkml.kernel.org/r/20171103185147.2688-2-pasha.tatas...@oracle.com > Signed-off-by: Andrey Ryabinin > Signed-off-by: Pavel Tatashin > Cc: Steven Sistare > Cc: Daniel Jordan > Cc: Bob Picco > Cc: Michal Hocko > Cc: Alexander Potapenko > Cc: Ard Biesheuvel > Cc: Catalin Marinas > Cc: Christian Borntraeger > Cc: David S. Miller > Cc: Dmitry Vyukov > Cc: Heiko Carstens > Cc: "H. Peter Anvin" > Cc: Ingo Molnar > Cc: Mark Rutland > Cc: Matthew Wilcox > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Sam Ravnborg > Cc: Thomas Gleixner > Cc: Will Deacon > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds > > a4a3ede213 mm: zero reserved and unavailable struct pages > d17a1d97dc x86/mm/kasan: don't use vmemmap_populate() to initialize shadow > 43570f0383 Merge branch 'linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 > 5bef2980ad Add linux-next specific files for 20171128 > +---++++---+ > | | a4a3ede213 | > d17a1d97dc | 43570f0383 | next-20171128 | > +---++++---+ > | boot_successes| 30 | 0 > | 0 | 0 | > | boot_failures | 8 | 15 > | 19 | 2 | > | WARNING:at_drivers/pci/pci-sysfs.c:#pci_mmap_resource | 8 | > || | > | RIP:pci_mmap_resource | 8 | > || | > | BUG:KASAN:use-after-scope_in__drm_mm_interval_first | 0 | 15 > | 19 | 2 | > +---++++---+ > > [ 27.628251] AMD IOMMUv2 functionality not available on this system > [ 27.631925] drm_mm: Testing DRM range manger (struct drm_mm), with > random_seed=0x248e657d max_iterations=8192 max_prime=128 > [ 27.633191] drm_mm: igt_sanitycheck - ok! > [ 79.880445] Writes: Total: 2 Max/Min: 0/0 Fail: 0 > [ 103.749567] > == > [ 103.750064] BUG: KASAN: use-after-scope in > __drm_mm_interval_first+0xbb/0x1bf > [ 103.750064] Read of size 8 at addr 880016577c08 by task swapper/0/1 > [ 103.750064] > [ 103.750064] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 4.14.0-04319-gd17a1d9 #1 > [ 103.750064] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.10.2-1 04/01/2014 > [ 103.750064] Call Trace: > [ 103.750064] ? dump_stack+0xd1/0x16c > [ 103.750064] ? _atomic_dec_and_lock+0x10f/0x10f > [ 103.750064] ? print_address_description+0x93/0x22e > [ 103.750064] ? __drm_mm_interval_first+0xbb/0x1bf > [ 103.750064] ? kasan_report+0x219/0x23f > [ 103.750064] ? __drm_mm_interval_first+0xbb/0x1bf > [ 103.750064] ? assert_continuous+0x13c/0x22f > [ 103.750064] ? drm_mm_replace_node+0x210/0x3ed > [ 103.750064] ? __igt_insert+0x5af/0xb3a > [ 103.750064] ? igt_bottomup+0x9e6/0x9e6 > [ 103.750064] ? kvm_clock_read+0x21/0x29 > [ 103.750064] ? kvm_sched_clock_read+0x5/0xd > [ 103.750064] ? sched_clock+0x5/0x8 > [ 103.750064] ? sch
Re: [syzbot] [fbdev?] KASAN: slab-out-of-bounds Read in fb_pad_unaligned_buffer (2)
On Mon, 11 Nov 2024 at 10:38, syzbot wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit:6efbea77b390 Merge tag 'arm64-fixes' of git://git.kernel.o.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=144e8c5f98 > kernel config: https://syzkaller.appspot.com/x/.config?x=4c9b3fd66df7ebb7 > dashboard link: https://syzkaller.appspot.com/bug?extid=6649e4a17d8ebca21a28 > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for > Debian) 2.40 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image (non-bootable): > https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-6efbea77.raw.xz > vmlinux: > https://storage.googleapis.com/syzbot-assets/fe29ba490b2c/vmlinux-6efbea77.xz > kernel image: > https://storage.googleapis.com/syzbot-assets/08bf31ef1152/bzImage-6efbea77.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+6649e4a17d8ebca21...@syzkaller.appspotmail.com > > == > BUG: KASAN: slab-out-of-bounds in fb_pad_unaligned_buffer+0x43c/0x470 > drivers/video/fbdev/core/fbmem.c:116 > Read of size 1 at addr 888041c73758 by task syz.3.3711/20535 > > CPU: 2 UID: 0 PID: 20535 Comm: syz.3.3711 Not tainted > 6.12.0-rc3-syzkaller-00183-g6efbea77b390 #0 > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 > Call Trace: > > __dump_stack lib/dump_stack.c:94 [inline] > dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 > print_address_description mm/kasan/report.c:377 [inline] > print_report+0xc3/0x620 mm/kasan/report.c:488 > kasan_report+0xd9/0x110 mm/kasan/report.c:601 > fb_pad_unaligned_buffer+0x43c/0x470 drivers/video/fbdev/core/fbmem.c:116 > bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:130 [inline] > bit_putcs+0x86a/0xdf0 drivers/video/fbdev/core/bitblit.c:188 > fbcon_putcs+0x364/0x480 drivers/video/fbdev/core/fbcon.c:1308 > do_update_region+0x1f8/0x3f0 drivers/tty/vt/vt.c:609 > update_region+0xc1/0x160 drivers/tty/vt/vt.c:633 > vcs_write+0x7cd/0xdb0 drivers/tty/vt/vc_screen.c:698 > do_loop_readv_writev fs/read_write.c:857 [inline] > do_loop_readv_writev fs/read_write.c:842 [inline] > vfs_writev+0x6da/0xdd0 fs/read_write.c:1066 > do_writev+0x137/0x370 fs/read_write.c: > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f20a6d7dff9 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f20a7aa2038 EFLAGS: 0246 ORIG_RAX: 0014 > RAX: ffda RBX: 7f20a6f36058 RCX: 7f20a6d7dff9 > RDX: 0004 RSI: 2a40 RDI: 0007 > RBP: 7f20a6df0296 R08: R09: > R10: R11: 0246 R12: > R13: R14: 7f20a6f36058 R15: 7ffc5a9e3328 > > > Allocated by task 18704: > kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 > kasan_save_track+0x14/0x30 mm/kasan/common.c:68 > poison_kmalloc_redzone mm/kasan/common.c:377 [inline] > __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 > kasan_kmalloc include/linux/kasan.h:257 [inline] > __do_kmalloc_node mm/slub.c:4264 [inline] > __kmalloc_noprof+0x1e8/0x400 mm/slub.c:4276 > kmalloc_noprof include/linux/slab.h:882 [inline] > fbcon_set_font+0x434/0xb60 drivers/video/fbdev/core/fbcon.c:2516 Is there synchronization between fbcon_do_set_font and uses of the font? fbcon_do_set_font sets data/width/height separately which potentially may cause such bugs (new data used with old width). > con_font_set drivers/tty/vt/vt.c:4804 [inline] > con_font_op+0x7fd/0xf50 drivers/tty/vt/vt.c:4851 > vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] > vt_ioctl+0x4ca/0x2f80 drivers/tty/vt/vt_ioctl.c:751 > tty_ioctl+0x651/0x15d0 drivers/tty/tty_io.c:2803 > vfs_ioctl fs/ioctl.c:51 [inline] > __do_sys_ioctl fs/ioctl.c:907 [inline] > __se_sys_ioctl fs/ioctl.c:893 [inline] > __x64_sys_ioctl+0x18f/0x220 fs/ioctl.c:893 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > The buggy address belongs to the object at 888041c7 > which belongs to the cache kmalloc-8k of size 8192 > The buggy address is located 6728 bytes to the right of > allocated 7440-byte region [888041c7, 888041c71d10) > > The buggy address belongs to the physical page: > page: refcount:1 mapcount:0 mapping: index:0x888041c74000 > pfn:0x41c70 > head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount
