* Re: [GIT PULL] SELinux patches for v5.5
From: Mimi Zohar @ 2019-12-03 2:00 UTC (permalink / raw)
To: Paul Moore; +Cc: selinux, linux-security-module, Roberto Sassu, initramfs
In-Reply-To: <CAHC9VhRkosCVR+4qyf=GPKQuQoJzwjZZJ_z7rhE-qiL-TNbtPw@mail.gmail.com>
On Mon, 2019-12-02 at 15:04 -0500, Paul Moore wrote:
> On Mon, Dec 2, 2019 at 10:58 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > [Truncated Cc list, adding Roberto and the initramfs mailing list]
> >
> > Hi Paul,
> >
> > On Tue, 2019-11-26 at 16:24 -0500, Paul Moore wrote:
> >
> > > - Allow file labeling before the policy is loaded. This should ease
> > > some of the burden when the policy is initially loaded (no need to
> > > relabel files), but it should also help enable some new system
> > > concepts which dynamically create the root filesystem in the initrd.
> >
> > Any chance you're planning on using Roberto's patches for including
> > security xattrs in the initramfs?[1]
> > [1] https://www.spinics.net/lists/linux-initramfs/msg04771.html
>
> I'm assuming you're not asking about me personally? ;)
No, of course not. I was wondering if "help enable some new system
concepts which dynamically create the root filesystem in the initrd"
adds SELinux labels on the root filesystem.
Mimi
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-03 2:13 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-security-module, dhowells, matthew.garrett
In-Reply-To: <201911301035.74813D4533@keescook>
I should also mention the kernel itself thinks it is vulnerable with the
MSRs locked down:
[ 7.367922] L1TF CPU bug present and SMT on, data leak possible. See
CVE-2018-3646 and
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
details.
On 11/30/19 12:36 PM, Kees Cook wrote:
> On Sat, Nov 30, 2019 at 12:49:48AM -0600, Matt Parnell wrote:
>> From 452b8460e464422d268659a8abb93353a182f8c8 Mon Sep 17 00:00:00 2001
>> From: Matt Parnell <mparnell@gmail.com>
>> Date: Sat, 30 Nov 2019 00:44:09 -0600
>> Subject: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even
>> in confidentiality mode.
>>
>> For Intel CPUs, some of the MDS mitigations utilize the new "flush" MSR, and
>> while this isn't something normally used in userspace, it does cause false
>> positives for the "Forshadow" vulnerability.
>>
>> Additionally, Intel CPUs use MSRs for voltage and frequency controls,
>> which in
>> many cases is useful for undervolting to avoid excess heat.
>>
>> Signed-off-by: Matt Parnell <mparnell@gmail.com>
> I would expect this to just be implemented via LSM policy, not ifdefs
> and Kconfig?
>
> -Kees
>
>> ---
>> arch/x86/kernel/msr.c | 5 ++++-
>> security/lockdown/Kconfig | 12 ++++++++++++
>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
>> index 1547be359d7f..4adce59455c3 100644
>> --- a/arch/x86/kernel/msr.c
>> +++ b/arch/x86/kernel/msr.c
>> @@ -80,10 +80,11 @@ static ssize_t msr_write(struct file *file, const
>> char __user *buf,
>> int err = 0;
>> ssize_t bytes = 0;
>>
>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>> err = security_locked_down(LOCKDOWN_MSR);
>> if (err)
>> return err;
>> -
>> +#endif
>> if (count % 8)
>> return -EINVAL; /* Invalid chunk size */
>>
>> @@ -135,9 +136,11 @@ static long msr_ioctl(struct file *file, unsigned
>> int ioc, unsigned long arg)
>> err = -EFAULT;
>> break;
>> }
>> +#if defined(LOCK_DOWN_DENY_RAW_MSR)
>> err = security_locked_down(LOCKDOWN_MSR);
>> if (err)
>> break;
>> +#endif
>> err = wrmsr_safe_regs_on_cpu(cpu, regs);
>> if (err)
>> break;
>> diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
>> index e84ddf484010..f4fe72c4bf8f 100644
>> --- a/security/lockdown/Kconfig
>> +++ b/security/lockdown/Kconfig
>> @@ -44,4 +44,16 @@ config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>> code to read confidential material held inside the kernel are
>> disabled.
>>
>> +config LOCK_DOWN_DENY_RAW_MSR
>> + bool "Lock down and deny raw MSR access"
>> + depends on LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
>> + default y
>> + help
>> + Some Intel based systems require raw MSR access to use the flush
>> + MSR for MDS mitigation confirmation. Raw access can also be used
>> + to undervolt many Intel CPUs.
>> +
>> + Say Y to prevent access or N to allow raw MSR access for such
>> + cases.
>> +
>> endchoice
>> --
>> 2.24.0
>>
>>
>
>
>
^ permalink raw reply
* Re: [GIT PULL] SELinux patches for v5.5
From: Paul Moore @ 2019-12-03 2:14 UTC (permalink / raw)
To: Mimi Zohar; +Cc: selinux, linux-security-module, Roberto Sassu, initramfs
In-Reply-To: <1575338427.4793.486.camel@linux.ibm.com>
On December 2, 2019 9:00:35 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Mon, 2019-12-02 at 15:04 -0500, Paul Moore wrote:
>> On Mon, Dec 2, 2019 at 10:58 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> [Truncated Cc list, adding Roberto and the initramfs mailing list]
>>>
>>> Hi Paul,
>>>
>>> On Tue, 2019-11-26 at 16:24 -0500, Paul Moore wrote:
>>>
>>>> - Allow file labeling before the policy is loaded. This should ease
>>>> some of the burden when the policy is initially loaded (no need to
>>>> relabel files), but it should also help enable some new system
>>>> concepts which dynamically create the root filesystem in the initrd.
>>>
>>> Any chance you're planning on using Roberto's patches for including
>>> security xattrs in the initramfs?[1]
>>> [1] https://www.spinics.net/lists/linux-initramfs/msg04771.html
>>
>> I'm assuming you're not asking about me personally? ;)
>
> No, of course not. I was wondering if "help enable some new system
> concepts which dynamically create the root filesystem in the initrd"
> adds SELinux labels on the root filesystem.
Once again, that is more of a distro specific question.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matthew Garrett @ 2019-12-03 2:16 UTC (permalink / raw)
To: Matt Parnell; +Cc: Kees Cook, LSM List, David Howells, matthew.garrett
In-Reply-To: <62ccc074-ac6d-edea-10c6-925f99dfc592@gmail.com>
On Mon, Dec 2, 2019 at 6:01 PM Matt Parnell <mparnell@gmail.com> wrote:
>
> I should also mention the kernel itself thinks it is vulnerable with the
> MSRs locked down:
>
> [ 7.367922] L1TF CPU bug present and SMT on, data leak possible. See
> CVE-2018-3646 and
> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
> details.
The lockdown code doesn't touch any of the codepaths the kernel uses
to access MSRs itself (a *lot* would break in that case), so if the
kernel is asserting this inappropriately then that seems like a kernel
bug.
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-03 2:24 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Kees Cook, LSM List, David Howells, matthew.garrett
In-Reply-To: <CACdnJuuDKX2GXZoubLGFoh8D3a1a38j+9rwu2iBZG6pqpqgokw@mail.gmail.com>
For what it is worth, this doesn't happen with lockdown disabled.
That message and the code that checks for mitigations is in
arch/x86/kvm/vmx/vmx.c - for some reason locking down the MSRs is even
making the kernel think that the MSR for the mitigation isn't there,
meaning that it is also likely not mitigating the bug.
On 12/2/19 8:16 PM, Matthew Garrett wrote:
> On Mon, Dec 2, 2019 at 6:01 PM Matt Parnell <mparnell@gmail.com> wrote:
>> I should also mention the kernel itself thinks it is vulnerable with the
>> MSRs locked down:
>>
>> [ 7.367922] L1TF CPU bug present and SMT on, data leak possible. See
>> CVE-2018-3646 and
>> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
>> details.
> The lockdown code doesn't touch any of the codepaths the kernel uses
> to access MSRs itself (a *lot* would break in that case), so if the
> kernel is asserting this inappropriately then that seems like a kernel
> bug.
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-03 2:50 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Kees Cook, LSM List, David Howells, matthew.garrett
In-Reply-To: <80b97dca-6eec-b008-81aa-74eb4f14ea0b@gmail.com>
Correction: I'm out of caffeine, tired, and it has made me an idiot.
That message triggers regardless, it seems. I apologize.
On 12/2/19 8:24 PM, Matt Parnell wrote:
> For what it is worth, this doesn't happen with lockdown disabled.
>
> That message and the code that checks for mitigations is in
> arch/x86/kvm/vmx/vmx.c - for some reason locking down the MSRs is even
> making the kernel think that the MSR for the mitigation isn't there,
> meaning that it is also likely not mitigating the bug.
>
> On 12/2/19 8:16 PM, Matthew Garrett wrote:
>> On Mon, Dec 2, 2019 at 6:01 PM Matt Parnell <mparnell@gmail.com> wrote:
>>> I should also mention the kernel itself thinks it is vulnerable with the
>>> MSRs locked down:
>>>
>>> [ 7.367922] L1TF CPU bug present and SMT on, data leak possible. See
>>> CVE-2018-3646 and
>>> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
>>> details.
>> The lockdown code doesn't touch any of the codepaths the kernel uses
>> to access MSRs itself (a *lot* would break in that case), so if the
>> kernel is asserting this inappropriately then that seems like a kernel
>> bug.
^ permalink raw reply
* Re: [PATCH] Kernel Lockdown: Add an option to allow raw MSR access even, in confidentiality mode.
From: Matt Parnell @ 2019-12-03 3:57 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Kees Cook, LSM List, David Howells, matthew.garrett
In-Reply-To: <b887b039-ebf6-5ef1-429e-04792f3cd664@gmail.com>
...possibly a bug on my older 4790k system, on my 8550u this doesn't
seem to happen. Strange.
Either way, I can stop bugging you if you'd like.
On 12/2/19 8:50 PM, Matt Parnell wrote:
> Correction: I'm out of caffeine, tired, and it has made me an idiot.
>
> That message triggers regardless, it seems. I apologize.
>
> On 12/2/19 8:24 PM, Matt Parnell wrote:
>> For what it is worth, this doesn't happen with lockdown disabled.
>>
>> That message and the code that checks for mitigations is in
>> arch/x86/kvm/vmx/vmx.c - for some reason locking down the MSRs is even
>> making the kernel think that the MSR for the mitigation isn't there,
>> meaning that it is also likely not mitigating the bug.
>>
>> On 12/2/19 8:16 PM, Matthew Garrett wrote:
>>> On Mon, Dec 2, 2019 at 6:01 PM Matt Parnell <mparnell@gmail.com> wrote:
>>>> I should also mention the kernel itself thinks it is vulnerable with the
>>>> MSRs locked down:
>>>>
>>>> [ 7.367922] L1TF CPU bug present and SMT on, data leak possible. See
>>>> CVE-2018-3646 and
>>>> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
>>>> details.
>>> The lockdown code doesn't touch any of the codepaths the kernel uses
>>> to access MSRs itself (a *lot* would break in that case), so if the
>>> kernel is asserting this inappropriately then that seems like a kernel
>>> bug.
^ permalink raw reply
* RE: [GIT PULL] SELinux patches for v5.5
From: Roberto Sassu @ 2019-12-03 7:57 UTC (permalink / raw)
To: Paul Moore, Mimi Zohar
Cc: selinux@vger.kernel.org, linux-security-module@vger.kernel.org,
initramfs, Silviu Vlasceanu
In-Reply-To: <16ec989f948.27df.85c95baa4474aabc7814e68940a78392@paul-moore.com>
> -----Original Message-----
> From: owner-linux-security-module@vger.kernel.org [mailto:owner-linux-
> security-module@vger.kernel.org] On Behalf Of Paul Moore
> Sent: Tuesday, December 3, 2019 3:15 AM
> To: Mimi Zohar <zohar@linux.ibm.com>
> Cc: selinux@vger.kernel.org; linux-security-module@vger.kernel.org;
> Roberto Sassu <roberto.sassu@huawei.com>; initramfs
> <initramfs@vger.kernel.org>
> Subject: Re: [GIT PULL] SELinux patches for v5.5
>
> On December 2, 2019 9:00:35 PM Mimi Zohar <zohar@linux.ibm.com>
> wrote:
>
> > On Mon, 2019-12-02 at 15:04 -0500, Paul Moore wrote:
> >> On Mon, Dec 2, 2019 at 10:58 AM Mimi Zohar <zohar@linux.ibm.com>
> wrote:
> >>> [Truncated Cc list, adding Roberto and the initramfs mailing list]
> >>>
> >>> Hi Paul,
> >>>
> >>> On Tue, 2019-11-26 at 16:24 -0500, Paul Moore wrote:
> >>>
> >>>> - Allow file labeling before the policy is loaded. This should ease
> >>>> some of the burden when the policy is initially loaded (no need to
> >>>> relabel files), but it should also help enable some new system
> >>>> concepts which dynamically create the root filesystem in the initrd.
> >>>
> >>> Any chance you're planning on using Roberto's patches for including
> >>> security xattrs in the initramfs?[1]
> >>> [1] https://www.spinics.net/lists/linux-initramfs/msg04771.html
> >>
> >> I'm assuming you're not asking about me personally? ;)
> >
> > No, of course not. I was wondering if "help enable some new system
> > concepts which dynamically create the root filesystem in the initrd"
> > adds SELinux labels on the root filesystem.
>
> Once again, that is more of a distro specific question.
If recent changes allow file labeling before the SELinux policy is loaded,
I think it would help the mechanism I developed. The SELinux label,
IMA/EVM signature can be included in the ram disk (standard CPIO image),
in a special file named METADATA!!! that follows the file xattrs are applied to.
Roberto
^ permalink raw reply
* Re: INFO: rcu detected stall in security_file_free
From: Dmitry Vyukov @ 2019-12-03 8:34 UTC (permalink / raw)
To: syzbot, Casey Schaufler, linux-security-module, Daniel Axtens,
Andrey Ryabinin, kasan-dev
Cc: Andrea Arcangeli, Andrew Morton, Christian Brauner, christian,
cyphar, Reshetova, Elena, Jason Gunthorpe, Kees Cook, ldv, LKML,
Andy Lutomirski, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
Thomas Gleixner, Al Viro, Will Drewry
In-Reply-To: <000000000000d5b2330598c87921@google.com>
On Tue, Dec 3, 2019 at 9:28 AM syzbot
<syzbot+6176df02eb1a01d00646@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1327942ae00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=9bbcda576154a4b4
> dashboard link: https://syzkaller.appspot.com/bug?extid=6176df02eb1a01d00646
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
>
> 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+6176df02eb1a01d00646@syzkaller.appspotmail.com
Something seriously broke in smack+kasan+vmap stacks, we now have 60
rcu stalls all over the place and counting. This is one of the
samples. Let's dup all of them to a single one and continue the
discussion there:
#syz dup: INFO: rcu detected stall in sys_kill
> rcu: INFO: rcu_preempt self-detected stall on CPU
> rcu: 0-...!: (10499 ticks this GP) idle=f6a/1/0x4000000000000002
> softirq=9928/9928 fqs=38
> (t=10501 jiffies g=6205 q=398)
> rcu: rcu_preempt kthread starved for 10424 jiffies! g6205 f0x0
> RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
> rcu: RCU grace-period kthread stack dump:
> rcu_preempt R running task 29032 10 2 0x80004000
> Call Trace:
> context_switch kernel/sched/core.c:3385 [inline]
> __schedule+0x9a0/0xcc0 kernel/sched/core.c:4081
> schedule+0x181/0x210 kernel/sched/core.c:4155
> schedule_timeout+0x14f/0x240 kernel/time/timer.c:1895
> rcu_gp_fqs_loop kernel/rcu/tree.c:1661 [inline]
> rcu_gp_kthread+0xed8/0x1770 kernel/rcu/tree.c:1821
> kthread+0x332/0x350 kernel/kthread.c:255
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> NMI backtrace for cpu 0
> CPU: 0 PID: 8045 Comm: syz-executor.5 Not tainted 5.4.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1fb/0x318 lib/dump_stack.c:118
> nmi_cpu_backtrace+0xaf/0x1a0 lib/nmi_backtrace.c:101
> nmi_trigger_cpumask_backtrace+0x174/0x290 lib/nmi_backtrace.c:62
> arch_trigger_cpumask_backtrace+0x10/0x20 arch/x86/kernel/apic/hw_nmi.c:38
> trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
> rcu_dump_cpu_stacks+0x15a/0x220 kernel/rcu/tree_stall.h:254
> print_cpu_stall kernel/rcu/tree_stall.h:455 [inline]
> check_cpu_stall kernel/rcu/tree_stall.h:529 [inline]
> rcu_pending kernel/rcu/tree.c:2827 [inline]
> rcu_sched_clock_irq+0xe25/0x1ad0 kernel/rcu/tree.c:2271
> update_process_times+0x12d/0x180 kernel/time/timer.c:1726
> tick_sched_handle kernel/time/tick-sched.c:167 [inline]
> tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1310
> __run_hrtimer kernel/time/hrtimer.c:1514 [inline]
> __hrtimer_run_queues+0x403/0x840 kernel/time/hrtimer.c:1576
> hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1638
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline]
> smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1135
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> </IRQ>
> RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50 kernel/kcov.c:98
> Code: 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 48 89 fb e8 13 00 00 00
> 48 8b 3d 34 e7 cc 07 48 89 de e8 64 02 3b 00 5b 5d c3 cc <48> 8b 04 24 65
> 48 8b 0c 25 c0 1d 02 00 65 8b 15 b8 81 8b 7e f7 c2
> RSP: 0018:ffffc90001f87a90 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
> RAX: 1ffff11013f36931 RBX: ffffea00029e3f40 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000fffffffc RDI: ffffea00029e3f40
> RBP: ffffc90001f87ab8 R08: dffffc0000000000 R09: fffffbfff120248a
> R10: fffffbfff120248a R11: 0000000000000000 R12: ffff88809f9b4a20
> R13: dffffc0000000000 R14: 00000000fffffffc R15: ffff8880a8747628
> free_thread_stack+0x168/0x590 kernel/fork.c:280
> release_task_stack kernel/fork.c:440 [inline]
> put_task_stack+0xa3/0x130 kernel/fork.c:451
> finish_task_switch+0x3f1/0x550 kernel/sched/core.c:3256
> context_switch kernel/sched/core.c:3388 [inline]
> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
> preempt_schedule_irq+0xc1/0x140 kernel/sched/core.c:4338
> retint_kernel+0x1b/0x2b
> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:752
> [inline]
> RIP: 0010:kmem_cache_free+0xc8/0xf0 mm/slab.c:3695
> Code: 58 07 00 74 42 4c 89 f7 57 9d 0f 1f 44 00 00 e8 0e 98 ca ff eb 19 e8
> a7 95 ca ff 48 83 3d 07 f7 58 07 00 74 24 4c 89 f7 57 9d <0f> 1f 44 00 00
> 4c 89 e7 4c 89 fe e8 58 01 00 00 5b 41 5c 41 5e 41
> RSP: 0018:ffffc90001f87d10 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
> RAX: ffff88809753ced4 RBX: ffff8880aa9eb000 RCX: ffff88809753c640
> RDX: 0000000000000000 RSI: ffffffff83474bc4 RDI: 0000000000000286
> RBP: ffffc90001f87d30 R08: ffff88809753ce98 R09: ffffc90001f87b14
> R10: 000000000000000b R11: 0000000000000000 R12: ffffffff83474bc4
> R13: ffff888095bf2cc0 R14: 0000000000000286 R15: ffff8880a304d1f8
> security_file_free+0xc4/0xe0 security/security.c:1403
> file_free fs/file_table.c:55 [inline]
> __fput+0x506/0x740 fs/file_table.c:298
> ____fput+0x15/0x20 fs/file_table.c:313
> task_work_run+0x17e/0x1b0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:188 [inline]
> exit_to_usermode_loop arch/x86/entry/common.c:164 [inline]
> prepare_exit_to_usermode+0x483/0x5b0 arch/x86/entry/common.c:195
> syscall_return_slowpath+0x113/0x4a0 arch/x86/entry/common.c:278
> do_syscall_64+0x11f/0x1c0 arch/x86/entry/common.c:304
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x45e433
> Code: 48 89 ee 48 89 e7 e8 2c 1f fa ff 31 c0 48 89 e2 be 33 89 00 00 89 df
> e8 bb c0 ff ff 85 c0 78 17 48 63 fb b8 03 00 00 00 0f 05 <8b> 44 24 10 48
> 83 c4 38 5b 5d c3 66 90 48 c7 c2 d4 ff ff ff 48 63
> RSP: 002b:00007ffe95171aa0 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 0000000000000004 RCX: 000000000045e433
> RDX: 00007ffe95171aa0 RSI: 0000000000008933 RDI: 0000000000000004
> RBP: 00000000004bfb19 R08: 000000000000000a R09: 000000000000000a
> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000003
> R13: 0000000000000006 R14: 0000000000000000 R15: 00007ffe95171d30
>
>
> ---
> 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 syzkaller@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+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000d5b2330598c87921%40google.com.
^ permalink raw reply
* Re: INFO: rcu detected stall in pipe_read
From: Dmitry Vyukov @ 2019-12-03 8:34 UTC (permalink / raw)
To: syzbot, Casey Schaufler, linux-security-module, Daniel Axtens,
Andrey Ryabinin, kasan-dev
Cc: Andrea Arcangeli, Andrew Morton, Christian Brauner, christian,
cyphar, Reshetova, Elena, Jason Gunthorpe, Kees Cook, ldv, LKML,
Andy Lutomirski, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
Thomas Gleixner, Al Viro, Will Drewry
In-Reply-To: <000000000000d2a8cc0598c8798f@google.com>
On Tue, Dec 3, 2019 at 9:28 AM syzbot
<syzbot+7047406d4ba783c8eb7b@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17b1af36e00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=9bbcda576154a4b4
> dashboard link: https://syzkaller.appspot.com/bug?extid=7047406d4ba783c8eb7b
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
>
> 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+7047406d4ba783c8eb7b@syzkaller.appspotmail.com
Something seriously broke in smack+kasan+vmap stacks, we now have 60
rcu stalls all over the place and counting. This is one of the
samples. Let's dup all of them to a single one and continue the
discussion there:
#syz dup: INFO: rcu detected stall in sys_kill
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> (detected by 0, t=10502 jiffies, g=5977, q=61)
> rcu: All QSes seen, last rcu_preempt kthread activity 10503
> (4294953644-4294943141), jiffies_till_next_fqs=1, root ->qsmask 0x0
> syz-executor.0 R running task 24296 8125 8124 0x0000400a
> Call Trace:
> <IRQ>
> sched_show_task+0x40f/0x560 kernel/sched/core.c:5954
> print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
> check_cpu_stall kernel/rcu/tree_stall.h:538 [inline]
> rcu_pending kernel/rcu/tree.c:2827 [inline]
> rcu_sched_clock_irq+0x1861/0x1ad0 kernel/rcu/tree.c:2271
> update_process_times+0x12d/0x180 kernel/time/timer.c:1726
> tick_sched_handle kernel/time/tick-sched.c:167 [inline]
> tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1310
> __run_hrtimer kernel/time/hrtimer.c:1514 [inline]
> __hrtimer_run_queues+0x403/0x840 kernel/time/hrtimer.c:1576
> hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1638
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline]
> smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1135
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> </IRQ>
> RIP: 0010:mod_memcg_page_state+0x2b/0x190 include/linux/memcontrol.h:653
> Code: 48 89 e5 41 57 41 56 41 54 53 41 89 f6 48 89 fb e8 da 28 2e 00 48 83
> c3 38 48 89 d8 48 c1 e8 03 49 bc 00 00 00 00 00 fc ff df <42> 80 3c 20 00
> 74 08 48 89 df e8 b6 9f 69 00 48 8b 1b 48 85 db 0f
> RSP: 0018:ffffc90001f27998 EFLAGS: 00000a02 ORIG_RAX: ffffffffffffff13
> RAX: 1ffffd40005452bf RBX: ffffea0002a295f8 RCX: ffff88808f094580
> RDX: 0000000000000000 RSI: 00000000fffffffc RDI: ffffea0002a295c0
> RBP: ffffc90001f279b8 R08: dffffc0000000000 R09: fffffbfff1287025
> R10: fffffbfff1287025 R11: 0000000000000000 R12: dffffc0000000000
> R13: dffffc0000000000 R14: 00000000fffffffc R15: ffff8880a8a6f4a8
> free_thread_stack+0x168/0x590 kernel/fork.c:280
> release_task_stack kernel/fork.c:440 [inline]
> put_task_stack+0xa3/0x130 kernel/fork.c:451
> finish_task_switch+0x3f1/0x550 kernel/sched/core.c:3256
> context_switch kernel/sched/core.c:3388 [inline]
> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
> preempt_schedule_common kernel/sched/core.c:4236 [inline]
> preempt_schedule+0xdb/0x120 kernel/sched/core.c:4261
> ___preempt_schedule+0x16/0x18 arch/x86/entry/thunk_64.S:50
> __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:161 [inline]
> _raw_spin_unlock_irqrestore+0xcc/0xe0 kernel/locking/spinlock.c:191
> spin_unlock_irqrestore include/linux/spinlock.h:393 [inline]
> __wake_up_common_lock kernel/sched/wait.c:125 [inline]
> __wake_up+0xe1/0x150 kernel/sched/wait.c:142
> pipe_read+0x8e1/0x9e0 fs/pipe.c:374
> call_read_iter include/linux/fs.h:1896 [inline]
> new_sync_read fs/read_write.c:414 [inline]
> __vfs_read+0x59e/0x730 fs/read_write.c:427
> vfs_read+0x1dd/0x420 fs/read_write.c:461
> ksys_read+0x117/0x220 fs/read_write.c:587
> __do_sys_read fs/read_write.c:597 [inline]
> __se_sys_read fs/read_write.c:595 [inline]
> __x64_sys_read+0x7b/0x90 fs/read_write.c:595
> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x414190
> Code: 01 f0 ff ff 0f 83 90 1b 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
> 44 00 00 83 3d dd 42 66 00 00 75 14 b8 00 00 00 00 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 64 1b 00 00 c3 48 83 ec 08 e8 6a fc ff ff
> RSP: 002b:00007fff84902588 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000414190
> RDX: 0000000000000038 RSI: 0000000000758040 RDI: 00000000000000f9
> RBP: 0000000000000002 R08: 00000000000003b8 R09: 0000000000004000
> R10: 0000000000717660 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fff849025c0 R14: 000000000000e9c4 R15: 00007fff849025d0
> rcu: rcu_preempt kthread starved for 10534 jiffies! g5977 f0x2
> RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> rcu: RCU grace-period kthread stack dump:
> rcu_preempt R running task 29104 10 2 0x80004000
> Call Trace:
> context_switch kernel/sched/core.c:3385 [inline]
> __schedule+0x9a0/0xcc0 kernel/sched/core.c:4081
> schedule+0x181/0x210 kernel/sched/core.c:4155
> schedule_timeout+0x14f/0x240 kernel/time/timer.c:1895
> rcu_gp_fqs_loop kernel/rcu/tree.c:1661 [inline]
> rcu_gp_kthread+0xed8/0x1770 kernel/rcu/tree.c:1821
> kthread+0x332/0x350 kernel/kthread.c:255
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>
>
> ---
> 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 syzkaller@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+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000d2a8cc0598c8798f%40google.com.
^ permalink raw reply
* Re: INFO: rcu detected stall in sys_kill
From: Dmitry Vyukov @ 2019-12-03 8:38 UTC (permalink / raw)
To: syzbot, Casey Schaufler, linux-security-module, Daniel Axtens,
Andrey Ryabinin, kasan-dev
Cc: Andrea Arcangeli, Andrew Morton, Christian Brauner, christian,
cyphar, Reshetova, Elena, Jason Gunthorpe, Kees Cook, ldv, LKML,
Andy Lutomirski, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
Thomas Gleixner, Al Viro, Will Drewry
In-Reply-To: <00000000000036decf0598c8762e@google.com>
On Tue, Dec 3, 2019 at 9:27 AM syzbot
<syzbot+de8d933e7d153aa0c1bb@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15f11c2ae00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=9bbcda576154a4b4
> dashboard link: https://syzkaller.appspot.com/bug?extid=de8d933e7d153aa0c1bb
> compiler: clang version 9.0.0 (/home/glider/llvm/clang
> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
>
> 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+de8d933e7d153aa0c1bb@syzkaller.appspotmail.com
Something seriously broken in smack+kasan+vmap stacks, we now have 60
rcu stalls all over the place and counting. This is one of the
samples. I've duped 2 other samples to this one, you can see them on
the dashboard:
https://syzkaller.appspot.com/bug?extid=de8d933e7d153aa0c1bb
I see 2 common this across all stalls:
1. They all happen on the instance that uses smack (which is now
effectively dead), see smack instance here:
https://syzkaller.appspot.com/upstream
2. They all contain this frame in the stack trace:
free_thread_stack+0x168/0x590 kernel/fork.c:280
The last commit that touches this file is "fork: support VMAP_STACK
with KASAN_VMALLOC".
That may be very likely the root cause. +Daniel
> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> (detected by 1, t=10502 jiffies, g=6629, q=331)
> rcu: All QSes seen, last rcu_preempt kthread activity 10503
> (4294953794-4294943291), jiffies_till_next_fqs=1, root ->qsmask 0x0
> syz-executor.0 R running task 24648 8293 8292 0x0000400a
> Call Trace:
> <IRQ>
> sched_show_task+0x40f/0x560 kernel/sched/core.c:5954
> print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
> check_cpu_stall kernel/rcu/tree_stall.h:538 [inline]
> rcu_pending kernel/rcu/tree.c:2827 [inline]
> rcu_sched_clock_irq+0x1861/0x1ad0 kernel/rcu/tree.c:2271
> update_process_times+0x12d/0x180 kernel/time/timer.c:1726
> tick_sched_handle kernel/time/tick-sched.c:167 [inline]
> tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1310
> __run_hrtimer kernel/time/hrtimer.c:1514 [inline]
> __hrtimer_run_queues+0x403/0x840 kernel/time/hrtimer.c:1576
> hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1638
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline]
> smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1135
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> </IRQ>
> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline]
> RIP: 0010:check_kcov_mode kernel/kcov.c:70 [inline]
> RIP: 0010:__sanitizer_cov_trace_pc+0x1c/0x50 kernel/kcov.c:102
> Code: cc 07 48 89 de e8 64 02 3b 00 5b 5d c3 cc 48 8b 04 24 65 48 8b 0c 25
> c0 1d 02 00 65 8b 15 b8 81 8b 7e f7 c2 00 01 1f 00 75 2c <8b> 91 80 13 00
> 00 83 fa 02 75 21 48 8b 91 88 13 00 00 48 8b 32 48
> RSP: 0018:ffffc900021c7c28 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
> RAX: ffffffff81487433 RBX: 0000000000000000 RCX: ffff88809428a100
> RDX: 0000000000000001 RSI: 00000000fffffffc RDI: ffffea0002479240
> RBP: ffffc900021c7c50 R08: dffffc0000000000 R09: fffffbfff1287025
> R10: fffffbfff1287025 R11: 0000000000000000 R12: dffffc0000000000
> R13: dffffc0000000000 R14: 00000000fffffffc R15: ffff888091c57428
> free_thread_stack+0x168/0x590 kernel/fork.c:280
> release_task_stack kernel/fork.c:440 [inline]
> put_task_stack+0xa3/0x130 kernel/fork.c:451
> finish_task_switch+0x3f1/0x550 kernel/sched/core.c:3256
> context_switch kernel/sched/core.c:3388 [inline]
> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
> preempt_schedule_common kernel/sched/core.c:4236 [inline]
> preempt_schedule+0xdb/0x120 kernel/sched/core.c:4261
> ___preempt_schedule+0x16/0x18 arch/x86/entry/thunk_64.S:50
> __raw_read_unlock include/linux/rwlock_api_smp.h:227 [inline]
> _raw_read_unlock+0x3a/0x40 kernel/locking/spinlock.c:255
> kill_something_info kernel/signal.c:1586 [inline]
> __do_sys_kill kernel/signal.c:3640 [inline]
> __se_sys_kill+0x5e9/0x6c0 kernel/signal.c:3634
> __x64_sys_kill+0x5b/0x70 kernel/signal.c:3634
> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x422a17
> Code: 44 00 00 48 c7 c2 d4 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e
> 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 3e 00 00 00 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 dd 32 ff ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fff38dca538 EFLAGS: 00000293 ORIG_RAX: 000000000000003e
> RAX: ffffffffffffffda RBX: 0000000000000064 RCX: 0000000000422a17
> RDX: 0000000000000bb8 RSI: 0000000000000009 RDI: 00000000fffffffe
> RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000001c62940
> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000008
> R13: 00007fff38dca570 R14: 000000000000f0b6 R15: 00007fff38dca580
> rcu: rcu_preempt kthread starved for 10533 jiffies! g6629 f0x2
> RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> rcu: RCU grace-period kthread stack dump:
> rcu_preempt R running task 29032 10 2 0x80004008
> Call Trace:
> context_switch kernel/sched/core.c:3388 [inline]
> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
> schedule+0x181/0x210 kernel/sched/core.c:4155
> schedule_timeout+0x14f/0x240 kernel/time/timer.c:1895
> rcu_gp_fqs_loop kernel/rcu/tree.c:1661 [inline]
> rcu_gp_kthread+0xed8/0x1770 kernel/rcu/tree.c:1821
> kthread+0x332/0x350 kernel/kthread.c:255
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>
>
> ---
> 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 syzkaller@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+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000036decf0598c8762e%40google.com.
^ permalink raw reply
* [GIT PULL] apparmor updates for 5.5
From: John Johansen @ 2019-12-03 20:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKLM, open list:SECURITY SUBSYSTEM
Hi Linus,
Sorry I didn't manage to get these out before last weeks vacation.
Can you please pull the following changes for apparmor
Thanks!
- John
The following changes since commit 582549e3fbe137eb6ce9be591aca25c2222a36b4:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-04-10 09:39:04 -1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor tags/apparmor-pr-2019-12-03
for you to fetch changes up to 341c1fda5e17156619fb71acfc7082b2669b4b72:
apparmor: make it so work buffers can be allocated from atomic context (2019-11-22 16:41:08 -0800)
----------------------------------------------------------------
+ Features
- increase left match history buffer size to provide inproved conflict
resolution in overlapping execution rules.
- switch buffer allocation to use a memory pool and GFP_KERNEL
where possible.
- add compression of policy blobs to reduce memory usage.
+ Cleanups
- fix spelling mistake "immutible" -> "immutable"
+ Bug fixes
- fix unsigned len comparison in update_for_len macro
- fix sparse warning for type-casting of current->real_cred
----------------------------------------------------------------
Bharath Vedartham (1):
apparmor: Force type-casting of current->real_cred
Chris Coulson (1):
apparmor: Initial implementation of raw policy blob compression
Colin Ian King (2):
apparmor: fix spelling mistake "immutible" -> "immutable"
apparmor: fix unsigned len comparison with less than zero
John Johansen (7):
apparmor: fix blob compression build failure on ppc
apparmor: fix missing ZLIB defines
apparmor: fix blob compression when ns is forced on a policy load
apparmor: increase left match history buffer size
apparmor: fix wrong buffer allocation in aa_new_mount
apparmor: reduce rcu_read_lock scope for aa_file_perm mediation
apparmor: make it so work buffers can be allocated from atomic context
Sebastian Andrzej Siewior (2):
apparmor: Use a memory pool instead per-CPU caches
apparmor: Switch to GFP_KERNEL where possible
security/apparmor/Kconfig | 2 +
security/apparmor/apparmorfs.c | 130 +++++++++++++++++++-
security/apparmor/domain.c | 46 +++----
security/apparmor/file.c | 45 ++++---
security/apparmor/include/apparmor.h | 1 +
security/apparmor/include/file.h | 2 +-
security/apparmor/include/match.h | 3 +-
security/apparmor/include/path.h | 50 +-------
security/apparmor/include/policy_unpack.h | 8 +-
security/apparmor/label.c | 12 +-
security/apparmor/lsm.c | 198 ++++++++++++++++++++++++------
security/apparmor/match.c | 6 +-
security/apparmor/mount.c | 67 +++++++---
security/apparmor/policy.c | 5 +-
security/apparmor/policy_unpack.c | 116 ++++++++++++++++-
15 files changed, 526 insertions(+), 165 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] apparmor updates for 5.5
From: Linus Torvalds @ 2019-12-03 21:00 UTC (permalink / raw)
To: John Johansen; +Cc: LKLM, open list:SECURITY SUBSYSTEM
In-Reply-To: <ab8e6cbb-c46d-41bd-0a0d-43530ee37386@canonical.com>
On Tue, Dec 3, 2019 at 12:33 PM John Johansen
<john.johansen@canonical.com> wrote:
>
> + Bug fixes
> - fix sparse warning for type-casting of current->real_cred
That fix is wrong.
Yes, it removes the warning.
It's still wrong.
The proper way to remove the warning is to use the proper accessor to
read the current real_cred. And that will point out that the cred
needs to be 'const'.
IOW, it should do
const struct cred *cred = current_real_cred();
instead.
I have done the pull without doing that change, but this is a REALLY
IMPORTANT issue! Don't just "fix warnings". The warnings had a reason,
you need to _think_ about them.
This is doubly true in code that claims to be about "security".
Seriously. apparmor can't just be a "let's do random things and hope
for the best".
Linus
^ permalink raw reply
* Re: [GIT PULL] apparmor updates for 5.5
From: pr-tracker-bot @ 2019-12-03 21:05 UTC (permalink / raw)
To: John Johansen; +Cc: Linus Torvalds, LKLM, open list:SECURITY SUBSYSTEM
In-Reply-To: <ab8e6cbb-c46d-41bd-0a0d-43530ee37386@canonical.com>
The pull request you sent on Tue, 3 Dec 2019 12:33:43 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor tags/apparmor-pr-2019-12-03
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/79e178a57dae819ae724065b47c25720494cc9f2
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: Daniel Vetter @ 2019-12-03 22:37 UTC (permalink / raw)
To: syzbot, Kentaro Takeda, Tetsuo Handa, James Morris,
Serge E. Hallyn, linux-security-module
Cc: Bartlomiej Zolnierkiewicz, Daniel Thompson, dri-devel, ghalat,
Linux Fbdev development list, Linux Kernel Mailing List,
Maarten Lankhorst, Sam Ravnborg, syzkaller-bugs
In-Reply-To: <0000000000002cfc3a0598d42b70@google.com>
On Tue, Dec 3, 2019 at 11:25 PM syzbot
<syzbot+4455ca3b3291de891abc@syzkaller.appspotmail.com> 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=10bfe282e00000
> 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=11181edae00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae00000
>
> 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.
-Daniel
>
> CPU: 0 PID: 9999 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:0x4444d9
> 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:00007fff6f4393b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007fff6f4393c0 RCX: 00000000004444d9
> RDX: 0000000020000440 RSI: 0000000000004b72 RDI: 0000000000000005
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000400da0
> R10: 00007fff6f438f00 R11: 0000000000000246 R12: 00000000004021e0
> R13: 0000000000402270 R14: 0000000000000000 R15: 0000000000000000
>
> Allocated by task 9999:
> 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 [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
>
> Freed by task 9771:
> save_stack+0x23/0x90 mm/kasan/common.c:71
> set_track mm/kasan/common.c:79 [inline]
> kasan_set_free_info mm/kasan/common.c:334 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/common.c:473
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:482
> __cache_free mm/slab.c:3426 [inline]
> kfree+0x10a/0x2c0 mm/slab.c:3757
> tomoyo_init_log+0x15c1/0x2070 security/tomoyo/audit.c:294
> tomoyo_supervisor+0x33f/0xef0 security/tomoyo/common.c:2095
> tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
> tomoyo_env_perm+0x18e/0x210 security/tomoyo/environ.c:63
> tomoyo_environ security/tomoyo/domain.c:670 [inline]
> tomoyo_find_next_domain+0x1354/0x1f6c security/tomoyo/domain.c:876
> tomoyo_bprm_check_security security/tomoyo/tomoyo.c:107 [inline]
> tomoyo_bprm_check_security+0x124/0x1a0 security/tomoyo/tomoyo.c:97
> security_bprm_check+0x63/0xb0 security/security.c:784
> search_binary_handler+0x71/0x570 fs/exec.c:1645
> exec_binprm fs/exec.c:1701 [inline]
> __do_execve_file.isra.0+0x1329/0x22b0 fs/exec.c:1821
> do_execveat_common fs/exec.c:1867 [inline]
> do_execve fs/exec.c:1884 [inline]
> __do_sys_execve fs/exec.c:1960 [inline]
> __se_sys_execve fs/exec.c:1955 [inline]
> __x64_sys_execve+0x8f/0xc0 fs/exec.c:1955
> do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff888094b0a000
> which belongs to the cache kmalloc-4k of size 4096
> The buggy address is located 2576 bytes inside of
> 4096-byte region [ffff888094b0a000, ffff888094b0b000)
> The buggy address belongs to the page:
> page:ffffea000252c280 refcount:1 mapcount:0 mapping:ffff8880aa402000
> index:0x0 compound_mapcount: 0
> raw: 00fffe0000010200 ffffea0002a3ae08 ffffea0002a6aa88 ffff8880aa402000
> raw: 0000000000000000 ffff888094b0a000 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff888094b0a900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff888094b0a980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff888094b0aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff888094b0aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff888094b0ab00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> 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 syzkaller@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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: Dmitry Vyukov @ 2019-12-04 6:33 UTC (permalink / raw)
To: Daniel Vetter, kasan-dev, Andrey Ryabinin
Cc: syzbot, Kentaro Takeda, Tetsuo Handa, James Morris,
Serge E. Hallyn, linux-security-module, Bartlomiej Zolnierkiewicz,
Daniel Thompson, dri-devel, ghalat, Linux Fbdev development list,
Linux Kernel Mailing List, Maarten Lankhorst, Sam Ravnborg,
syzkaller-bugs
In-Reply-To: <CAKMK7uFAfw4M6B8WaHx6FBkYDmUBTQ6t3D8RE5BbMt=_5vyp9A@mail.gmail.com>
On Tue, Dec 3, 2019 at 11:37 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> On Tue, Dec 3, 2019 at 11:25 PM syzbot
> <syzbot+4455ca3b3291de891abc@syzkaller.appspotmail.com> 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=10bfe282e00000
> > 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=11181edae00000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae00000
> >
> > 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?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: 9999 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:0x4444d9
> > 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:00007fff6f4393b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > RAX: ffffffffffffffda RBX: 00007fff6f4393c0 RCX: 00000000004444d9
> > RDX: 0000000020000440 RSI: 0000000000004b72 RDI: 0000000000000005
> > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000400da0
> > R10: 00007fff6f438f00 R11: 0000000000000246 R12: 00000000004021e0
> > R13: 0000000000402270 R14: 0000000000000000 R15: 0000000000000000
> >
> > Allocated by task 9999:
> > 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 [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
> >
> > Freed by task 9771:
> > save_stack+0x23/0x90 mm/kasan/common.c:71
> > set_track mm/kasan/common.c:79 [inline]
> > kasan_set_free_info mm/kasan/common.c:334 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:473
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:482
> > __cache_free mm/slab.c:3426 [inline]
> > kfree+0x10a/0x2c0 mm/slab.c:3757
> > tomoyo_init_log+0x15c1/0x2070 security/tomoyo/audit.c:294
> > tomoyo_supervisor+0x33f/0xef0 security/tomoyo/common.c:2095
> > tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
> > tomoyo_env_perm+0x18e/0x210 security/tomoyo/environ.c:63
> > tomoyo_environ security/tomoyo/domain.c:670 [inline]
> > tomoyo_find_next_domain+0x1354/0x1f6c security/tomoyo/domain.c:876
> > tomoyo_bprm_check_security security/tomoyo/tomoyo.c:107 [inline]
> > tomoyo_bprm_check_security+0x124/0x1a0 security/tomoyo/tomoyo.c:97
> > security_bprm_check+0x63/0xb0 security/security.c:784
> > search_binary_handler+0x71/0x570 fs/exec.c:1645
> > exec_binprm fs/exec.c:1701 [inline]
> > __do_execve_file.isra.0+0x1329/0x22b0 fs/exec.c:1821
> > do_execveat_common fs/exec.c:1867 [inline]
> > do_execve fs/exec.c:1884 [inline]
> > __do_sys_execve fs/exec.c:1960 [inline]
> > __se_sys_execve fs/exec.c:1955 [inline]
> > __x64_sys_execve+0x8f/0xc0 fs/exec.c:1955
> > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff888094b0a000
> > which belongs to the cache kmalloc-4k of size 4096
> > The buggy address is located 2576 bytes inside of
> > 4096-byte region [ffff888094b0a000, ffff888094b0b000)
> > The buggy address belongs to the page:
> > page:ffffea000252c280 refcount:1 mapcount:0 mapping:ffff8880aa402000
> > index:0x0 compound_mapcount: 0
> > raw: 00fffe0000010200 ffffea0002a3ae08 ffffea0002a6aa88 ffff8880aa402000
> > raw: 0000000000000000 ffff888094b0a000 0000000100000001 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff888094b0a900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff888094b0a980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > ffff888094b0aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ^
> > ffff888094b0aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff888094b0ab00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ==================================================================
> >
> >
> > ---
> > 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 syzkaller@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
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: Daniel Vetter @ 2019-12-04 9:15 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: kasan-dev, Andrey Ryabinin, syzbot, Kentaro Takeda, Tetsuo Handa,
James Morris, Serge E. Hallyn, linux-security-module,
Bartlomiej Zolnierkiewicz, Daniel Thompson, dri-devel, ghalat,
Linux Fbdev development list, Linux Kernel Mailing List,
Maarten Lankhorst, Sam Ravnborg, syzkaller-bugs
In-Reply-To: <CACT4Y+aV9vzJ6gs9r2RAQP+dQ_vkOc5H6hWu-prF1ECruAE_5w@mail.gmail.com>
On Wed, Dec 4, 2019 at 7:33 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Dec 3, 2019 at 11:37 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > On Tue, Dec 3, 2019 at 11:25 PM syzbot
> > <syzbot+4455ca3b3291de891abc@syzkaller.appspotmail.com> 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=10bfe282e00000
> > > 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=11181edae00000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae00000
> > >
> > > 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?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.
Ugh, that's indeed very confusing, thanks for explaining.
-Daniel
>
>
> > > CPU: 0 PID: 9999 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:0x4444d9
> > > 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:00007fff6f4393b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > > RAX: ffffffffffffffda RBX: 00007fff6f4393c0 RCX: 00000000004444d9
> > > RDX: 0000000020000440 RSI: 0000000000004b72 RDI: 0000000000000005
> > > RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000400da0
> > > R10: 00007fff6f438f00 R11: 0000000000000246 R12: 00000000004021e0
> > > R13: 0000000000402270 R14: 0000000000000000 R15: 0000000000000000
> > >
> > > Allocated by task 9999:
> > > 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 [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
> > >
> > > Freed by task 9771:
> > > save_stack+0x23/0x90 mm/kasan/common.c:71
> > > set_track mm/kasan/common.c:79 [inline]
> > > kasan_set_free_info mm/kasan/common.c:334 [inline]
> > > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:473
> > > kasan_slab_free+0xe/0x10 mm/kasan/common.c:482
> > > __cache_free mm/slab.c:3426 [inline]
> > > kfree+0x10a/0x2c0 mm/slab.c:3757
> > > tomoyo_init_log+0x15c1/0x2070 security/tomoyo/audit.c:294
> > > tomoyo_supervisor+0x33f/0xef0 security/tomoyo/common.c:2095
> > > tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
> > > tomoyo_env_perm+0x18e/0x210 security/tomoyo/environ.c:63
> > > tomoyo_environ security/tomoyo/domain.c:670 [inline]
> > > tomoyo_find_next_domain+0x1354/0x1f6c security/tomoyo/domain.c:876
> > > tomoyo_bprm_check_security security/tomoyo/tomoyo.c:107 [inline]
> > > tomoyo_bprm_check_security+0x124/0x1a0 security/tomoyo/tomoyo.c:97
> > > security_bprm_check+0x63/0xb0 security/security.c:784
> > > search_binary_handler+0x71/0x570 fs/exec.c:1645
> > > exec_binprm fs/exec.c:1701 [inline]
> > > __do_execve_file.isra.0+0x1329/0x22b0 fs/exec.c:1821
> > > do_execveat_common fs/exec.c:1867 [inline]
> > > do_execve fs/exec.c:1884 [inline]
> > > __do_sys_execve fs/exec.c:1960 [inline]
> > > __se_sys_execve fs/exec.c:1955 [inline]
> > > __x64_sys_execve+0x8f/0xc0 fs/exec.c:1955
> > > do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > The buggy address belongs to the object at ffff888094b0a000
> > > which belongs to the cache kmalloc-4k of size 4096
> > > The buggy address is located 2576 bytes inside of
> > > 4096-byte region [ffff888094b0a000, ffff888094b0b000)
> > > The buggy address belongs to the page:
> > > page:ffffea000252c280 refcount:1 mapcount:0 mapping:ffff8880aa402000
> > > index:0x0 compound_mapcount: 0
> > > raw: 00fffe0000010200 ffffea0002a3ae08 ffffea0002a6aa88 ffff8880aa402000
> > > raw: 0000000000000000 ffff888094b0a000 0000000100000001 0000000000000000
> > > page dumped because: kasan: bad access detected
> > >
> > > Memory state around the buggy address:
> > > ffff888094b0a900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > ffff888094b0a980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > > ffff888094b0aa00: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > ^
> > > ffff888094b0aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > ffff888094b0ab00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > > ==================================================================
> > >
> > >
> > > ---
> > > 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 syzkaller@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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v2] tomoyo: Don't check open/getattr permission on sockets.
From: Tetsuo Handa @ 2019-12-04 12:50 UTC (permalink / raw)
To: James Morris
Cc: Andrew Morton, Stephen Rothwell, linux-security-module,
Linus Torvalds
In-Reply-To: <b7263da2-d56d-0f27-a7e5-03541ff8a0c1@i-love.sakura.ne.jp>
On 2019/11/21 22:59, Tetsuo Handa wrote:
> On 2019/11/21 19:18, Tetsuo Handa wrote:
>> On 2019/11/21 16:21, James Morris wrote:
>>> On Wed, 13 Nov 2019, Tetsuo Handa wrote:
>>>
>>>> Hello, Andrew and James.
>>>>
>>>> I have difficulty setting up environments for sending pull request to linux.git
>>>> (nobody around me knows Linux kernel maintainer's workflow at the command line level).
>>>> Can you pick up the following commit via mmotm or linux-security.git tree?
>>>
>>> Not sure if your fix is complete.
>>>
>>> Are there other potential paths to trigger this via tomoyo_path_perm() ?
>>>
>>> e.g. call unlink(2) on /proc/pid/fd/sockfd
>>
>> I think they are safe. For example, unlink(2) checks that
>> inode is valid before calling security_path_unlink().
>
> Hmm, since unlink(2) locks parent's inode instead of inode to be removed itself,
> there is indeed possibility that tomoyo_path_perm() races with __sock_release().
> We need another patch...
>
I decided to drop tomoyo_get_socket_name(). Will you pick up the following commit?
commit c39593ab0500fcd6db290b311c120349927ddc04
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon Nov 25 10:46:51 2019 +0900
tomoyo: Don't use nifty names on sockets.
^ permalink raw reply
* Re: INFO: rcu detected stall in sys_kill
From: Dmitry Vyukov @ 2019-12-04 13:58 UTC (permalink / raw)
To: syzbot, Casey Schaufler, linux-security-module, Daniel Axtens,
Andrey Ryabinin, kasan-dev
Cc: Andrea Arcangeli, Andrew Morton, Christian Brauner, christian,
cyphar, Reshetova, Elena, Jason Gunthorpe, Kees Cook, ldv, LKML,
Andy Lutomirski, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
Thomas Gleixner, Al Viro, Will Drewry
In-Reply-To: <CACT4Y+YVMUxeLcFMray9n0+cXbVibj5X347LZr8YgvjN5nC8pw@mail.gmail.com>
On Tue, Dec 3, 2019 at 9:38 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Dec 3, 2019 at 9:27 AM syzbot
> <syzbot+de8d933e7d153aa0c1bb@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15f11c2ae00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=9bbcda576154a4b4
> > dashboard link: https://syzkaller.appspot.com/bug?extid=de8d933e7d153aa0c1bb
> > compiler: clang version 9.0.0 (/home/glider/llvm/clang
> > 80fee25776c2fb61e74c1ecb1a523375c2500b69)
> >
> > 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+de8d933e7d153aa0c1bb@syzkaller.appspotmail.com
>
> Something seriously broken in smack+kasan+vmap stacks, we now have 60
> rcu stalls all over the place and counting. This is one of the
> samples. I've duped 2 other samples to this one, you can see them on
> the dashboard:
> https://syzkaller.appspot.com/bug?extid=de8d933e7d153aa0c1bb
>
> I see 2 common this across all stalls:
> 1. They all happen on the instance that uses smack (which is now
> effectively dead), see smack instance here:
> https://syzkaller.appspot.com/upstream
> 2. They all contain this frame in the stack trace:
> free_thread_stack+0x168/0x590 kernel/fork.c:280
> The last commit that touches this file is "fork: support VMAP_STACK
> with KASAN_VMALLOC".
> That may be very likely the root cause. +Daniel
I've stopped smack syzbot instance b/c it produces infinite stream of
assorted crashes due to this.
Please ping syzkaller@googlegroups.com when this is fixed, I will
re-enable the instance.
> > rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> > (detected by 1, t=10502 jiffies, g=6629, q=331)
> > rcu: All QSes seen, last rcu_preempt kthread activity 10503
> > (4294953794-4294943291), jiffies_till_next_fqs=1, root ->qsmask 0x0
> > syz-executor.0 R running task 24648 8293 8292 0x0000400a
> > Call Trace:
> > <IRQ>
> > sched_show_task+0x40f/0x560 kernel/sched/core.c:5954
> > print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
> > check_cpu_stall kernel/rcu/tree_stall.h:538 [inline]
> > rcu_pending kernel/rcu/tree.c:2827 [inline]
> > rcu_sched_clock_irq+0x1861/0x1ad0 kernel/rcu/tree.c:2271
> > update_process_times+0x12d/0x180 kernel/time/timer.c:1726
> > tick_sched_handle kernel/time/tick-sched.c:167 [inline]
> > tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1310
> > __run_hrtimer kernel/time/hrtimer.c:1514 [inline]
> > __hrtimer_run_queues+0x403/0x840 kernel/time/hrtimer.c:1576
> > hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1638
> > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline]
> > smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1135
> > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > </IRQ>
> > RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline]
> > RIP: 0010:check_kcov_mode kernel/kcov.c:70 [inline]
> > RIP: 0010:__sanitizer_cov_trace_pc+0x1c/0x50 kernel/kcov.c:102
> > Code: cc 07 48 89 de e8 64 02 3b 00 5b 5d c3 cc 48 8b 04 24 65 48 8b 0c 25
> > c0 1d 02 00 65 8b 15 b8 81 8b 7e f7 c2 00 01 1f 00 75 2c <8b> 91 80 13 00
> > 00 83 fa 02 75 21 48 8b 91 88 13 00 00 48 8b 32 48
> > RSP: 0018:ffffc900021c7c28 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
> > RAX: ffffffff81487433 RBX: 0000000000000000 RCX: ffff88809428a100
> > RDX: 0000000000000001 RSI: 00000000fffffffc RDI: ffffea0002479240
> > RBP: ffffc900021c7c50 R08: dffffc0000000000 R09: fffffbfff1287025
> > R10: fffffbfff1287025 R11: 0000000000000000 R12: dffffc0000000000
> > R13: dffffc0000000000 R14: 00000000fffffffc R15: ffff888091c57428
> > free_thread_stack+0x168/0x590 kernel/fork.c:280
> > release_task_stack kernel/fork.c:440 [inline]
> > put_task_stack+0xa3/0x130 kernel/fork.c:451
> > finish_task_switch+0x3f1/0x550 kernel/sched/core.c:3256
> > context_switch kernel/sched/core.c:3388 [inline]
> > __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
> > preempt_schedule_common kernel/sched/core.c:4236 [inline]
> > preempt_schedule+0xdb/0x120 kernel/sched/core.c:4261
> > ___preempt_schedule+0x16/0x18 arch/x86/entry/thunk_64.S:50
> > __raw_read_unlock include/linux/rwlock_api_smp.h:227 [inline]
> > _raw_read_unlock+0x3a/0x40 kernel/locking/spinlock.c:255
> > kill_something_info kernel/signal.c:1586 [inline]
> > __do_sys_kill kernel/signal.c:3640 [inline]
> > __se_sys_kill+0x5e9/0x6c0 kernel/signal.c:3634
> > __x64_sys_kill+0x5b/0x70 kernel/signal.c:3634
> > do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x422a17
> > Code: 44 00 00 48 c7 c2 d4 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e
> > 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 3e 00 00 00 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 dd 32 ff ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007fff38dca538 EFLAGS: 00000293 ORIG_RAX: 000000000000003e
> > RAX: ffffffffffffffda RBX: 0000000000000064 RCX: 0000000000422a17
> > RDX: 0000000000000bb8 RSI: 0000000000000009 RDI: 00000000fffffffe
> > RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000001c62940
> > R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000008
> > R13: 00007fff38dca570 R14: 000000000000f0b6 R15: 00007fff38dca580
> > rcu: rcu_preempt kthread starved for 10533 jiffies! g6629 f0x2
> > RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
> > rcu: RCU grace-period kthread stack dump:
> > rcu_preempt R running task 29032 10 2 0x80004008
> > Call Trace:
> > context_switch kernel/sched/core.c:3388 [inline]
> > __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
> > schedule+0x181/0x210 kernel/sched/core.c:4155
> > schedule_timeout+0x14f/0x240 kernel/time/timer.c:1895
> > rcu_gp_fqs_loop kernel/rcu/tree.c:1661 [inline]
> > rcu_gp_kthread+0xed8/0x1770 kernel/rcu/tree.c:1821
> > kthread+0x332/0x350 kernel/kthread.c:255
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> >
> >
> > ---
> > 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 syzkaller@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+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000036decf0598c8762e%40google.com.
^ permalink raw reply
* Re: INFO: rcu detected stall in sys_kill
From: Casey Schaufler @ 2019-12-04 16:05 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot, linux-security-module, Daniel Axtens,
Andrey Ryabinin, kasan-dev
Cc: Andrea Arcangeli, Andrew Morton, Christian Brauner, christian,
cyphar, Reshetova, Elena, Jason Gunthorpe, Kees Cook, ldv, LKML,
Andy Lutomirski, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
Thomas Gleixner, Al Viro, Will Drewry, Casey Schaufler
In-Reply-To: <CACT4Y+asdED7tYv462Ui2OhQVKXVUnC+=fumXR3qM1A4d6AvOQ@mail.gmail.com>
On 12/4/2019 5:58 AM, Dmitry Vyukov wrote:
> On Tue, Dec 3, 2019 at 9:38 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Tue, Dec 3, 2019 at 9:27 AM syzbot
>> <syzbot+de8d933e7d153aa0c1bb@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 596cf45c Merge branch 'akpm' (patches from Andrew)
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=15f11c2ae00000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9bbcda576154a4b4
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=de8d933e7d153aa0c1bb
>>> compiler: clang version 9.0.0 (/home/glider/llvm/clang
>>> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
>>>
>>> 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+de8d933e7d153aa0c1bb@syzkaller.appspotmail.com
>> Something seriously broken in smack+kasan+vmap stacks, we now have 60
>> rcu stalls all over the place and counting. This is one of the
>> samples. I've duped 2 other samples to this one, you can see them on
>> the dashboard:
>> https://syzkaller.appspot.com/bug?extid=de8d933e7d153aa0c1bb
There haven't been Smack changes recently, so this is
going to have been introduced elsewhere. I'm perfectly
willing to accept that Smack is doing something horribly
wrong WRT rcu, and that it needs repair, but its going to
be tough for me to track down. I hope someone else is looking
into this, as my chances of finding the problem are pretty
slim.
>>
>> I see 2 common this across all stalls:
>> 1. They all happen on the instance that uses smack (which is now
>> effectively dead), see smack instance here:
>> https://syzkaller.appspot.com/upstream
>> 2. They all contain this frame in the stack trace:
>> free_thread_stack+0x168/0x590 kernel/fork.c:280
>> The last commit that touches this file is "fork: support VMAP_STACK
>> with KASAN_VMALLOC".
>> That may be very likely the root cause. +Daniel
> I've stopped smack syzbot instance b/c it produces infinite stream of
> assorted crashes due to this.
> Please ping syzkaller@googlegroups.com when this is fixed, I will
> re-enable the instance.
>
>>> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
>>> (detected by 1, t=10502 jiffies, g=6629, q=331)
>>> rcu: All QSes seen, last rcu_preempt kthread activity 10503
>>> (4294953794-4294943291), jiffies_till_next_fqs=1, root ->qsmask 0x0
>>> syz-executor.0 R running task 24648 8293 8292 0x0000400a
>>> Call Trace:
>>> <IRQ>
>>> sched_show_task+0x40f/0x560 kernel/sched/core.c:5954
>>> print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
>>> check_cpu_stall kernel/rcu/tree_stall.h:538 [inline]
>>> rcu_pending kernel/rcu/tree.c:2827 [inline]
>>> rcu_sched_clock_irq+0x1861/0x1ad0 kernel/rcu/tree.c:2271
>>> update_process_times+0x12d/0x180 kernel/time/timer.c:1726
>>> tick_sched_handle kernel/time/tick-sched.c:167 [inline]
>>> tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1310
>>> __run_hrtimer kernel/time/hrtimer.c:1514 [inline]
>>> __hrtimer_run_queues+0x403/0x840 kernel/time/hrtimer.c:1576
>>> hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1638
>>> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline]
>>> smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1135
>>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
>>> </IRQ>
>>> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline]
>>> RIP: 0010:check_kcov_mode kernel/kcov.c:70 [inline]
>>> RIP: 0010:__sanitizer_cov_trace_pc+0x1c/0x50 kernel/kcov.c:102
>>> Code: cc 07 48 89 de e8 64 02 3b 00 5b 5d c3 cc 48 8b 04 24 65 48 8b 0c 25
>>> c0 1d 02 00 65 8b 15 b8 81 8b 7e f7 c2 00 01 1f 00 75 2c <8b> 91 80 13 00
>>> 00 83 fa 02 75 21 48 8b 91 88 13 00 00 48 8b 32 48
>>> RSP: 0018:ffffc900021c7c28 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
>>> RAX: ffffffff81487433 RBX: 0000000000000000 RCX: ffff88809428a100
>>> RDX: 0000000000000001 RSI: 00000000fffffffc RDI: ffffea0002479240
>>> RBP: ffffc900021c7c50 R08: dffffc0000000000 R09: fffffbfff1287025
>>> R10: fffffbfff1287025 R11: 0000000000000000 R12: dffffc0000000000
>>> R13: dffffc0000000000 R14: 00000000fffffffc R15: ffff888091c57428
>>> free_thread_stack+0x168/0x590 kernel/fork.c:280
>>> release_task_stack kernel/fork.c:440 [inline]
>>> put_task_stack+0xa3/0x130 kernel/fork.c:451
>>> finish_task_switch+0x3f1/0x550 kernel/sched/core.c:3256
>>> context_switch kernel/sched/core.c:3388 [inline]
>>> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
>>> preempt_schedule_common kernel/sched/core.c:4236 [inline]
>>> preempt_schedule+0xdb/0x120 kernel/sched/core.c:4261
>>> ___preempt_schedule+0x16/0x18 arch/x86/entry/thunk_64.S:50
>>> __raw_read_unlock include/linux/rwlock_api_smp.h:227 [inline]
>>> _raw_read_unlock+0x3a/0x40 kernel/locking/spinlock.c:255
>>> kill_something_info kernel/signal.c:1586 [inline]
>>> __do_sys_kill kernel/signal.c:3640 [inline]
>>> __se_sys_kill+0x5e9/0x6c0 kernel/signal.c:3634
>>> __x64_sys_kill+0x5b/0x70 kernel/signal.c:3634
>>> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
>>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>> RIP: 0033:0x422a17
>>> Code: 44 00 00 48 c7 c2 d4 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e
>>> 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 3e 00 00 00 0f 05 <48> 3d 01 f0 ff
>>> ff 0f 83 dd 32 ff ff c3 66 2e 0f 1f 84 00 00 00 00
>>> RSP: 002b:00007fff38dca538 EFLAGS: 00000293 ORIG_RAX: 000000000000003e
>>> RAX: ffffffffffffffda RBX: 0000000000000064 RCX: 0000000000422a17
>>> RDX: 0000000000000bb8 RSI: 0000000000000009 RDI: 00000000fffffffe
>>> RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000001c62940
>>> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000008
>>> R13: 00007fff38dca570 R14: 000000000000f0b6 R15: 00007fff38dca580
>>> rcu: rcu_preempt kthread starved for 10533 jiffies! g6629 f0x2
>>> RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
>>> rcu: RCU grace-period kthread stack dump:
>>> rcu_preempt R running task 29032 10 2 0x80004008
>>> Call Trace:
>>> context_switch kernel/sched/core.c:3388 [inline]
>>> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
>>> schedule+0x181/0x210 kernel/sched/core.c:4155
>>> schedule_timeout+0x14f/0x240 kernel/time/timer.c:1895
>>> rcu_gp_fqs_loop kernel/rcu/tree.c:1661 [inline]
>>> rcu_gp_kthread+0xed8/0x1770 kernel/rcu/tree.c:1821
>>> kthread+0x332/0x350 kernel/kthread.c:255
>>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>>>
>>>
>>> ---
>>> 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 syzkaller@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+unsubscribe@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000036decf0598c8762e%40google.com.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: Andrey Ryabinin @ 2019-12-04 20:49 UTC (permalink / raw)
To: Dmitry Vyukov, Daniel Vetter, kasan-dev
Cc: syzbot, Kentaro Takeda, Tetsuo Handa, James Morris,
Serge E. Hallyn, linux-security-module, Bartlomiej Zolnierkiewicz,
Daniel Thompson, dri-devel, ghalat, Linux Fbdev development list,
Linux Kernel Mailing List, Maarten Lankhorst, Sam Ravnborg,
syzkaller-bugs
In-Reply-To: <CACT4Y+aV9vzJ6gs9r2RAQP+dQ_vkOc5H6hWu-prF1ECruAE_5w@mail.gmail.com>
On 12/4/19 9:33 AM, Dmitry Vyukov wrote:
> On Tue, Dec 3, 2019 at 11:37 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>
>> On Tue, Dec 3, 2019 at 11:25 PM syzbot
>> <syzbot+4455ca3b3291de891abc@syzkaller.appspotmail.com> 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=10bfe282e00000
>>> 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=11181edae00000
>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae00000
>>>
>>> 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?id=198425 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.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: syzbot @ 2019-12-04 21:41 UTC (permalink / raw)
To: aryabinin, b.zolnierkie, daniel.thompson, daniel.vetter,
dri-devel, dvyukov, ghalat, gleb, gwshan, hpa, jmorris, kasan-dev,
kvm, linux-fbdev, linux-kernel, linux-security-module,
maarten.lankhorst, mingo, mpe, pbonzini, penguin-kernel, ruscur,
sam, serge, stewart, syzkaller-bugs, takedakn, tglx, x86
In-Reply-To: <0000000000002cfc3a0598d42b70@google.com>
syzbot has bisected this bug to:
commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
Author: Russell Currey <ruscur@russell.cc>
Date: Mon Feb 8 04:08:20 2016 +0000
powerpc/powernv: Remove support for p5ioc2
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127a042ae00000
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=117a042ae00000
console output: https://syzkaller.appspot.com/x/log.txt?x=167a042ae00000
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=11181edae00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae00000
Reported-by: syzbot+4455ca3b3291de891abc@syzkaller.appspotmail.com
Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: INFO: rcu detected stall in sys_kill
From: Daniel Axtens @ 2019-12-04 23:34 UTC (permalink / raw)
To: Casey Schaufler, Dmitry Vyukov, syzbot, linux-security-module,
Andrey Ryabinin, kasan-dev
Cc: Andrea Arcangeli, Andrew Morton, Christian Brauner, christian,
cyphar, Reshetova, Elena, Jason Gunthorpe, Kees Cook, ldv, LKML,
Andy Lutomirski, Ingo Molnar, Peter Zijlstra, syzkaller-bugs,
Thomas Gleixner, Al Viro, Will Drewry, Casey Schaufler
In-Reply-To: <f7758e0a-a157-56a2-287e-3d4452d72e00@schaufler-ca.com>
Hi Casey,
> There haven't been Smack changes recently, so this is
> going to have been introduced elsewhere. I'm perfectly
> willing to accept that Smack is doing something horribly
> wrong WRT rcu, and that it needs repair, but its going to
> be tough for me to track down. I hope someone else is looking
> into this, as my chances of finding the problem are pretty
> slim.
Yeah, I'm having a look, it's probably related to my kasan-vmalloc
stuff. It's currently in a bit of flux as syzkaller finds a bunch of
other bugs with it, once that stablises a bit I'll come back to Smack.
Regards,
Daniel
>
>>>
>>> I see 2 common this across all stalls:
>>> 1. They all happen on the instance that uses smack (which is now
>>> effectively dead), see smack instance here:
>>> https://syzkaller.appspot.com/upstream
>>> 2. They all contain this frame in the stack trace:
>>> free_thread_stack+0x168/0x590 kernel/fork.c:280
>>> The last commit that touches this file is "fork: support VMAP_STACK
>>> with KASAN_VMALLOC".
>>> That may be very likely the root cause. +Daniel
>> I've stopped smack syzbot instance b/c it produces infinite stream of
>> assorted crashes due to this.
>> Please ping syzkaller@googlegroups.com when this is fixed, I will
>> re-enable the instance.
>>
>>>> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
>>>> (detected by 1, t=10502 jiffies, g=6629, q=331)
>>>> rcu: All QSes seen, last rcu_preempt kthread activity 10503
>>>> (4294953794-4294943291), jiffies_till_next_fqs=1, root ->qsmask 0x0
>>>> syz-executor.0 R running task 24648 8293 8292 0x0000400a
>>>> Call Trace:
>>>> <IRQ>
>>>> sched_show_task+0x40f/0x560 kernel/sched/core.c:5954
>>>> print_other_cpu_stall kernel/rcu/tree_stall.h:410 [inline]
>>>> check_cpu_stall kernel/rcu/tree_stall.h:538 [inline]
>>>> rcu_pending kernel/rcu/tree.c:2827 [inline]
>>>> rcu_sched_clock_irq+0x1861/0x1ad0 kernel/rcu/tree.c:2271
>>>> update_process_times+0x12d/0x180 kernel/time/timer.c:1726
>>>> tick_sched_handle kernel/time/tick-sched.c:167 [inline]
>>>> tick_sched_timer+0x263/0x420 kernel/time/tick-sched.c:1310
>>>> __run_hrtimer kernel/time/hrtimer.c:1514 [inline]
>>>> __hrtimer_run_queues+0x403/0x840 kernel/time/hrtimer.c:1576
>>>> hrtimer_interrupt+0x38c/0xda0 kernel/time/hrtimer.c:1638
>>>> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline]
>>>> smp_apic_timer_interrupt+0x109/0x280 arch/x86/kernel/apic/apic.c:1135
>>>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
>>>> </IRQ>
>>>> RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline]
>>>> RIP: 0010:check_kcov_mode kernel/kcov.c:70 [inline]
>>>> RIP: 0010:__sanitizer_cov_trace_pc+0x1c/0x50 kernel/kcov.c:102
>>>> Code: cc 07 48 89 de e8 64 02 3b 00 5b 5d c3 cc 48 8b 04 24 65 48 8b 0c 25
>>>> c0 1d 02 00 65 8b 15 b8 81 8b 7e f7 c2 00 01 1f 00 75 2c <8b> 91 80 13 00
>>>> 00 83 fa 02 75 21 48 8b 91 88 13 00 00 48 8b 32 48
>>>> RSP: 0018:ffffc900021c7c28 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
>>>> RAX: ffffffff81487433 RBX: 0000000000000000 RCX: ffff88809428a100
>>>> RDX: 0000000000000001 RSI: 00000000fffffffc RDI: ffffea0002479240
>>>> RBP: ffffc900021c7c50 R08: dffffc0000000000 R09: fffffbfff1287025
>>>> R10: fffffbfff1287025 R11: 0000000000000000 R12: dffffc0000000000
>>>> R13: dffffc0000000000 R14: 00000000fffffffc R15: ffff888091c57428
>>>> free_thread_stack+0x168/0x590 kernel/fork.c:280
>>>> release_task_stack kernel/fork.c:440 [inline]
>>>> put_task_stack+0xa3/0x130 kernel/fork.c:451
>>>> finish_task_switch+0x3f1/0x550 kernel/sched/core.c:3256
>>>> context_switch kernel/sched/core.c:3388 [inline]
>>>> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
>>>> preempt_schedule_common kernel/sched/core.c:4236 [inline]
>>>> preempt_schedule+0xdb/0x120 kernel/sched/core.c:4261
>>>> ___preempt_schedule+0x16/0x18 arch/x86/entry/thunk_64.S:50
>>>> __raw_read_unlock include/linux/rwlock_api_smp.h:227 [inline]
>>>> _raw_read_unlock+0x3a/0x40 kernel/locking/spinlock.c:255
>>>> kill_something_info kernel/signal.c:1586 [inline]
>>>> __do_sys_kill kernel/signal.c:3640 [inline]
>>>> __se_sys_kill+0x5e9/0x6c0 kernel/signal.c:3634
>>>> __x64_sys_kill+0x5b/0x70 kernel/signal.c:3634
>>>> do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294
>>>> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>>>> RIP: 0033:0x422a17
>>>> Code: 44 00 00 48 c7 c2 d4 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 2e
>>>> 0f 1f 84 00 00 00 00 00 0f 1f 40 00 b8 3e 00 00 00 0f 05 <48> 3d 01 f0 ff
>>>> ff 0f 83 dd 32 ff ff c3 66 2e 0f 1f 84 00 00 00 00
>>>> RSP: 002b:00007fff38dca538 EFLAGS: 00000293 ORIG_RAX: 000000000000003e
>>>> RAX: ffffffffffffffda RBX: 0000000000000064 RCX: 0000000000422a17
>>>> RDX: 0000000000000bb8 RSI: 0000000000000009 RDI: 00000000fffffffe
>>>> RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000001c62940
>>>> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000008
>>>> R13: 00007fff38dca570 R14: 000000000000f0b6 R15: 00007fff38dca580
>>>> rcu: rcu_preempt kthread starved for 10533 jiffies! g6629 f0x2
>>>> RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
>>>> rcu: RCU grace-period kthread stack dump:
>>>> rcu_preempt R running task 29032 10 2 0x80004008
>>>> Call Trace:
>>>> context_switch kernel/sched/core.c:3388 [inline]
>>>> __schedule+0x9a8/0xcc0 kernel/sched/core.c:4081
>>>> schedule+0x181/0x210 kernel/sched/core.c:4155
>>>> schedule_timeout+0x14f/0x240 kernel/time/timer.c:1895
>>>> rcu_gp_fqs_loop kernel/rcu/tree.c:1661 [inline]
>>>> rcu_gp_kthread+0xed8/0x1770 kernel/rcu/tree.c:1821
>>>> kthread+0x332/0x350 kernel/kthread.c:255
>>>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>>>>
>>>>
>>>> ---
>>>> 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 syzkaller@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+unsubscribe@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000036decf0598c8762e%40google.com.
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: Tetsuo Handa @ 2019-12-05 1:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz, Daniel Vetter, Maarten Lankhorst,
Sam Ravnborg, Grzegorz Halat
Cc: syzbot, aryabinin, daniel.thompson, dri-devel, dvyukov, gleb,
gwshan, hpa, jmorris, kasan-dev, kvm, linux-fbdev, linux-kernel,
linux-security-module, mingo, mpe, pbonzini, ruscur, serge,
stewart, syzkaller-bugs, takedakn, tglx, x86
In-Reply-To: <0000000000003e640e0598e7abc3@google.com>
Hello.
syzbot is reporting that memory allocation size at fbcon_set_font() is too small
because font's height is rounded up from 10 to 16 after memory allocation.
----------
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c9235a2f42f8..68fe66e435d3 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2461,6 +2461,7 @@ static int fbcon_get_font(struct vc_data *vc, struct console_font *font)
if (font->width <= 8) {
j = vc->vc_font.height;
+ printk("ksize(fontdata)=%lu font->charcount=%d vc->vc_font.height=%d font->width=%u\n", ksize(fontdata), font->charcount, j, font->width);
for (i = 0; i < font->charcount; i++) {
memcpy(data, fontdata, j);
memset(data + j, 0, 32 - j);
@@ -2661,6 +2662,8 @@ static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
size = h * pitch * charcount;
new_data = kmalloc(FONT_EXTRA_WORDS * sizeof(int) + size, GFP_USER);
+ if (new_data)
+ printk("ksize(new_data)=%lu h=%u pitch=%u charcount=%u font->width=%u\n", ksize(new_data), h, pitch, charcount, font->width);
if (!new_data)
return -ENOMEM;
----------
Normal usage:
[ 27.305293] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.328527] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.362551] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.385084] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.387653] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.417562] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.437808] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.440738] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.461157] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.495346] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.607372] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.655674] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.675310] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
[ 27.702193] ksize(new_data)=8192 h=16 pitch=1 charcount=256 font->width=8
syzbot's testcase:
[ 115.784893] ksize(new_data)=4096 h=10 pitch=1 charcount=256 font->width=8
[ 115.790269] ksize(fontdata)=4096 font->charcount=256 vc->vc_font.height=16 font->width=8
^ permalink raw reply related
* Re: KASAN: slab-out-of-bounds Read in fbcon_get_font
From: Paolo Bonzini @ 2019-12-05 10:13 UTC (permalink / raw)
To: syzbot, aryabinin, b.zolnierkie, daniel.thompson, daniel.vetter,
dri-devel, dvyukov, ghalat, gleb, gwshan, hpa, jmorris, kasan-dev,
kvm, linux-fbdev, linux-kernel, linux-security-module,
maarten.lankhorst, mingo, mpe, penguin-kernel, ruscur, sam, serge,
stewart, syzkaller-bugs, takedakn, tglx, x86
In-Reply-To: <0000000000003e640e0598e7abc3@google.com>
On 04/12/19 22:41, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
> Author: Russell Currey <ruscur@russell.cc>
> Date: Mon Feb 8 04:08:20 2016 +0000
>
> powerpc/powernv: Remove support for p5ioc2
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127a042ae00000
> 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=117a042ae00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=167a042ae00000
> 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=11181edae00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105cbb7ae00000
>
> Reported-by: syzbot+4455ca3b3291de891abc@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?
Thanks,
Paolo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox