Thread (17 messages) 17 messages, 6 authors, 2019-12-05

Re: KASAN: slab-out-of-bounds Read in fbcon_get_font

From: Andrey Ryabinin <hidden>
Date: 2019-12-04 20:52:33
Also in: dri-devel, linux-security-module, lkml


On 12/4/19 9:33 AM, Dmitry Vyukov wrote:
On Tue, Dec 3, 2019 at 11:37 PM Daniel Vetter [off-list ref] wrote:
quoted
On Tue, Dec 3, 2019 at 11:25 PM syzbot
[off-list ref] wrote:
quoted
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?xbfe282e00000
kernel config:  https://syzkaller.appspot.com/x/.config?xÝ226651cb0f364b
dashboard link: https://syzkaller.appspot.com/bug?extidD55ca3b3291de891abc
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x181edae00000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x5cbb7ae00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4455ca3b3291de891abc@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 ffff888094b0aa10 by task syz-executor414/9999
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?id8425 which I think is a
good idea, I will add your confusion as a data point :)
Because we have that information (free stack) and it usually better to provide
all the information we have rather than hide it. You never known what information
might be needed to fix the bug.
Free memory might be reused and what we report as OOB might be an UAF and free stack
could be useful in such case.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help