From: Greg KH <gregkh@linuxfoundation.org>
To: Or Cohen <orcohen@paloaltonetworks.com>
Cc: jslaby@suse.com, nico@fluxnic.net, textshell@uchuujin.de,
daniel.vetter@ffwll.ch, sam@ravnborg.org, mpatocka@redhat.com,
ghalat@redhat.com, linux-kernel@vger.kernel.org, jwilk@jwilk.net,
Nadav Markus <nmarkus@paloaltonetworks.com>,
syzkaller@googlegroups.com
Subject: Re: Bug report - slab-out-of-bounds in vcs_scr_readw
Date: Mon, 4 Nov 2019 16:24:28 +0100 [thread overview]
Message-ID: <20191104152428.GA2252441@kroah.com> (raw)
In-Reply-To: <CAM6JnLeEnvjjQPyLeh+8dt5wGNud_vks5k_eXJZy2T1H7ao=hQ@mail.gmail.com>
On Mon, Nov 04, 2019 at 04:39:55AM -0800, Or Cohen wrote:
> Hi,
> I discovered a OOB access bug using Syzkaller and decided to report it,
> as I could not find a similar report in syzkaller mailing list,
> syzkaller-bugs mailing list
> or syzbot dashboard. ( as described in:
> https://github.com/google/syzkaller/blob/master/docs/linux/reporting_kernel_bugs.md
> )
>
> I've tested it and the bug reproduces on the following versions:
>
> commit 4d856f72c10ecb060868ed10ff1b1453943fc6c8 (HEAD, tag: v5.3)
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sun Sep 15 14:19:32 2019 -0700
> Linux 5.3
>
> commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d (grafted, HEAD, tag: v4.19)
> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Mon Oct 22 07:37:37 2018 +0100
> Linux 4.19
>
> The call stack at the time of the crash is as follows: (kernel 5.3)
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x88/0xce lib/dump_stack.c:113
> print_address_description+0x60/0x31f mm/kasan/report.c:351
> __kasan_report.cold.6+0x1a/0x3c mm/kasan/report.c:482
> kasan_report+0xe/0x12 mm/kasan/common.c:618
> vcs_scr_readw+0xb1/0xc0 drivers/tty/vt/vt.c:4665
> vcs_write+0x5c2/0xbb0 drivers/tty/vt/vc_screen.c:545
> do_loop_readv_writev fs/read_write.c:717 [inline]
> do_loop_readv_writev fs/read_write.c:701 [inline]
> do_iter_write fs/read_write.c:972 [inline]
> do_iter_write+0x47b/0x5f0 fs/read_write.c:951
> vfs_writev+0x1b3/0x2f0 fs/read_write.c:1015
> do_writev+0x11f/0x2e0 fs/read_write.c:1058
> do_syscall_64+0xb7/0x3a0 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>
> The overwritten buffer is of size 4000 bytes and is allocated in:
> vc_allocate+0x3b0/0x6d0 drivers/tty/vt/vt.c:1098
>
> >From my brief analysis of the "vcs_write" function ( vc_screen.c ), it
> seems like the
> "screen_pos" function (line 548) is used to return a pointer into the
> overwritten buffer:
>
> 540: while (this_round > 0) {
> 541: unsigned char c = *con_buf0++;
> 542:
> 543: this_round--;
> 544: vcs_scr_writew(vc,
> 545: vcs_scr_readw(vc, org) & 0xff00) | c, org);
> 546: org++;
> 547: if (++col == maxcol) {
> 548: org = screen_pos(vc, p, viewed);
> 549: col = 0;
> 550: p += maxcol;
> 551: }
> 552: }
>
> The "count" argument ( controlled from user space ) affects the
> initialization
> of "this_round".
> After several iterations of the while loop, "screen_pos" returns a pointer
> to offset
> 4000 into the buffer which leads KASAN to detect it as an OOB read of 2
> bytes in "vcs_scr_readw".
> We can see however, that immediately after that "vcs_scr_writew" is called
> which
> leads to a write of 2 bytes past the end of the buffer.
>
> The following files are attached:
> repro.c - A C reproducer for the bug.
Your repo.c file is "interesting" saying you have a giant buffer, yet it
really is just 1 byte long. Does that have something to do with the
problem here?
I am at another conference at the moment and can't look at this much
now, will try to later this week...
thanks,
greg k-h
next parent reply other threads:[~2019-11-04 15:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAM6JnLeEnvjjQPyLeh+8dt5wGNud_vks5k_eXJZy2T1H7ao=hQ@mail.gmail.com>
2019-11-04 15:24 ` Greg KH [this message]
2019-11-04 15:50 ` Bug report - slab-out-of-bounds in vcs_scr_readw Nicolas Pitre
2019-11-04 16:15 ` Or Cohen
2019-11-04 18:33 ` Nicolas Pitre
2019-11-05 6:54 ` Jiri Slaby
2019-11-05 9:03 ` Or Cohen
2019-11-05 9:14 ` Jiri Slaby
2019-11-05 9:33 ` Nicolas Pitre
2019-11-05 10:29 ` Jiri Slaby
2019-11-05 10:53 ` Dmitry Vyukov
2019-11-05 13:44 ` Nicolas Pitre
2019-11-06 17:01 ` Or Cohen
2019-11-26 21:55 ` Nicolas Pitre
2019-11-27 6:45 ` Greg KH
2019-11-27 16:24 ` Nicolas Pitre
2019-11-27 16:30 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191104152428.GA2252441@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=daniel.vetter@ffwll.ch \
--cc=ghalat@redhat.com \
--cc=jslaby@suse.com \
--cc=jwilk@jwilk.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=nico@fluxnic.net \
--cc=nmarkus@paloaltonetworks.com \
--cc=orcohen@paloaltonetworks.com \
--cc=sam@ravnborg.org \
--cc=syzkaller@googlegroups.com \
--cc=textshell@uchuujin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).