All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Dmitry Vyukov" <dvyukov@google.com>
Cc: <alsa-devel@alsa-project.org>,
	"Julia Lawall" <Julia.Lawall@lip6.fr>,
	"Jaroslav Kysela" <perex@perex.cz>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Alexander Potapenko" <glider@google.com>,
	"Kostya Serebryany" <kcc@google.com>,
	"syzkaller" <syzkaller@googlegroups.com>,
	"Sasha Levin" <sasha.levin@oracle.com>
Subject: Re: sound: heap out-of-bounds write in dummy_systimer_prepare
Date: Thu, 28 Jan 2016 07:38:08 +0100	[thread overview]
Message-ID: <s5hoac6mcof.wl-tiwai@suse.de> (raw)
In-Reply-To: <CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com>

On Wed, 27 Jan 2016 10:55:45 +0100,
Dmitry Vyukov wrote:
> 
> Hello,
> 
> I've got the following report while running syzkaller fuzzer:
> 
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in dummy_systimer_prepare+0x268/0x2a0
> at addr ffff88006067aa30
> Write of size 4 by task syz-executor/5841
> =============================================================================
> BUG kmalloc-192 (Not tainted): kasan: bad access detected
> -----------------------------------------------------------------------------
> 
> INFO: Allocated in dummy_hrtimer_create+0x49/0x1a0 age=77 cpu=2 pid=5841
> [<     inline     >] slab_alloc_node mm/slub.c:2562
> [<     inline     >] slab_alloc mm/slub.c:2604
> [<      none      >] kmem_cache_alloc_trace+0x25c/0x300 mm/slub.c:2621
> [<     inline     >] kmalloc include/linux/slab.h:463
> [<     inline     >] kzalloc include/linux/slab.h:607
> [<      none      >] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:458
> [<      none      >] dummy_pcm_open+0xef/0x570 sound/drivers/dummy.c:573
> [<      none      >] snd_pcm_open_substream+0x188/0x430
> sound/core/pcm_native.c:2264
> [<     inline     >] snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2342
> [<      none      >] snd_pcm_oss_open.part.17+0x5a4/0x1110
> sound/core/oss/pcm_oss.c:2424
> [<      none      >] snd_pcm_oss_open+0x35/0x50 sound/core/oss/pcm_oss.c:2388
> [<      none      >] soundcore_open+0x30f/0x640 sound/sound_core.c:639
> [<      none      >] chrdev_open+0x22a/0x4c0 fs/char_dev.c:388
> [<      none      >] do_dentry_open+0x6a2/0xcb0 fs/open.c:736
> [<      none      >] vfs_open+0x17b/0x1f0 fs/open.c:853
> [<     inline     >] do_last fs/namei.c:3254
> [<      none      >] path_openat+0xde9/0x5e30 fs/namei.c:3386
> [<      none      >] do_filp_open+0x18e/0x250 fs/namei.c:3421
> [<      none      >] do_sys_open+0x1fc/0x420 fs/open.c:1022
> [<     inline     >] SYSC_open fs/open.c:1040
> [<      none      >] SyS_open+0x2d/0x40 fs/open.c:1035
> 
> INFO: Slab 0xffffea0001819e00 objects=24 used=20 fp=0xffff8800606799f0
> flags=0x5fffc0000004080
> INFO: Object 0xffff88006067a980 @offset=10624 fp=0x          (null)
> CPU: 2 PID: 5841 Comm: syz-executor Tainted: G    B           4.5.0-rc1+ #291
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  00000000ffffffff ffff8800316af4c8 ffffffff829e798d ffff88003e804c00
>  ffff88006067a980 ffff880060678000 ffff8800316af4f8 ffffffff8175b394
>  ffff88003e804c00 ffffea0001819e00 ffff88006067a980 0000000000008002
> 
> Call Trace:
>  [<     inline     >] kasan_report mm/kasan/report.c:274
>  [<ffffffff81764ebe>] __asan_report_store4_noabort+0x3e/0x40
> mm/kasan/report.c:299
>  [<ffffffff850dc078>] dummy_systimer_prepare+0x268/0x2a0
> sound/drivers/dummy.c:295
>  [<ffffffff850dc52b>] dummy_pcm_prepare+0x7b/0xa0 sound/drivers/dummy.c:512
>  [<ffffffff8505159a>] snd_pcm_do_prepare+0x5a/0x90 sound/core/pcm_native.c:1512
>  [<ffffffff85050886>] snd_pcm_action_single+0x76/0x120
> sound/core/pcm_native.c:944
>  [<ffffffff85050c85>] snd_pcm_action_nonatomic+0x95/0xa0
> sound/core/pcm_native.c:1011
>  [<     inline     >] snd_pcm_prepare sound/core/pcm_native.c:1552
>  [<ffffffff8505bbd5>] snd_pcm_common_ioctl1+0x1045/0x21a0
> sound/core/pcm_native.c:2765
>  [<ffffffff8505cfd2>] snd_pcm_playback_ioctl1+0x2a2/0x5e0
> sound/core/pcm_native.c:2884
>  [<ffffffff8505dad6>] snd_pcm_kernel_ioctl+0x136/0x160
> sound/core/pcm_native.c:3004
>  [<ffffffff8508bb4b>] snd_pcm_oss_prepare+0x4b/0x200
> sound/core/oss/pcm_oss.c:1112
>  [<ffffffff850941ee>] snd_pcm_oss_make_ready+0xae/0x120
> sound/core/oss/pcm_oss.c:1140
>  [<ffffffff85096d5a>] snd_pcm_oss_sync+0xba/0xa30 sound/core/oss/pcm_oss.c:1609
>  [<ffffffff8509787d>] snd_pcm_oss_release+0x1ad/0x280
> sound/core/oss/pcm_oss.c:2479
>  [<ffffffff817c0096>] __fput+0x236/0x780 fs/file_table.c:208
>  [<ffffffff817c0665>] ____fput+0x15/0x20 fs/file_table.c:244
>  [<ffffffff813b13c0>] task_work_run+0x170/0x210 kernel/task_work.c:115
>  [<     inline     >] exit_task_work include/linux/task_work.h:21
>  [<ffffffff8135ca55>] do_exit+0x8b5/0x2cb0 kernel/exit.c:748
>  [<ffffffff8135efc8>] do_group_exit+0x108/0x330 kernel/exit.c:878
>  [<ffffffff81382114>] get_signal+0x5e4/0x14f0 kernel/signal.c:2307
>  [<ffffffff811a0db3>] do_signal+0x83/0x1c90 arch/x86/kernel/signal.c:712
>  [<ffffffff81006685>] exit_to_usermode_loop+0x1a5/0x210
> arch/x86/entry/common.c:247
>  [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:282
>  [<ffffffff810084ea>] syscall_return_slowpath+0x2ba/0x340
> arch/x86/entry/common.c:344
>  [<ffffffff86459c22>] int_ret_from_sys_call+0x25/0x9f
> arch/x86/entry/entry_64.S:281
> 
> Memory state around the buggy address:
>  ffff88006067a900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff88006067a980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffff88006067aa00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
>                                      ^
>  ffff88006067aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff88006067ab00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
> 
> 
> The timer is created by dummy_hrtimer_create as hrtimer, but then
> accessed by dummy_systimer_prepare as systimer. The root cause seems
> to be a data race on dummy->timer_ops which is reinitialized while it
> is being used already. The race in turn causes type confusion. Which
> in turn causes heap overwrite with known values.
> 
> I was able to reproduce this by working with sound devices and doing
> "echo -n N > /sys/module/snd_dummy/parameters/hrtimer" concurrently.
> But I am sure that syzkaller did not do writes to sysfs when this bug
> was triggered, not sure what altered hrtimer variable in that case. Or
> do you see any other possibilities for this issue to be triggered?

I don't see any other possibilities.

The easiest fix for this is obviously to disable the switch via
sysfs like below.  Meanwhile we may copy the ops to the runtime
instance so that it won't affect the running stream.  This can be done
for 4.6, while disabling sysfs for 4.5 and stable.


thanks,

Takashi

---
diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
index 75b74850c005..bde33308f0d6 100644
--- a/sound/drivers/dummy.c
+++ b/sound/drivers/dummy.c
@@ -87,7 +87,7 @@ MODULE_PARM_DESC(pcm_substreams, "PCM substreams # (1-128) for dummy driver.");
 module_param(fake_buffer, bool, 0444);
 MODULE_PARM_DESC(fake_buffer, "Fake buffer allocations.");
 #ifdef CONFIG_HIGH_RES_TIMERS
-module_param(hrtimer, bool, 0644);
+module_param(hrtimer, bool, 0444);
 MODULE_PARM_DESC(hrtimer, "Use hrtimer as the timer source.");
 #endif
 

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: alsa-devel@alsa-project.org, Julia Lawall <Julia.Lawall@lip6.fr>,
	LKML <linux-kernel@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	syzkaller <syzkaller@googlegroups.com>,
	Alexander Potapenko <glider@google.com>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: sound: heap out-of-bounds write in dummy_systimer_prepare
Date: Thu, 28 Jan 2016 07:38:08 +0100	[thread overview]
Message-ID: <s5hoac6mcof.wl-tiwai@suse.de> (raw)
In-Reply-To: <CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com>

On Wed, 27 Jan 2016 10:55:45 +0100,
Dmitry Vyukov wrote:
> 
> Hello,
> 
> I've got the following report while running syzkaller fuzzer:
> 
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in dummy_systimer_prepare+0x268/0x2a0
> at addr ffff88006067aa30
> Write of size 4 by task syz-executor/5841
> =============================================================================
> BUG kmalloc-192 (Not tainted): kasan: bad access detected
> -----------------------------------------------------------------------------
> 
> INFO: Allocated in dummy_hrtimer_create+0x49/0x1a0 age=77 cpu=2 pid=5841
> [<     inline     >] slab_alloc_node mm/slub.c:2562
> [<     inline     >] slab_alloc mm/slub.c:2604
> [<      none      >] kmem_cache_alloc_trace+0x25c/0x300 mm/slub.c:2621
> [<     inline     >] kmalloc include/linux/slab.h:463
> [<     inline     >] kzalloc include/linux/slab.h:607
> [<      none      >] dummy_hrtimer_create+0x49/0x1a0 sound/drivers/dummy.c:458
> [<      none      >] dummy_pcm_open+0xef/0x570 sound/drivers/dummy.c:573
> [<      none      >] snd_pcm_open_substream+0x188/0x430
> sound/core/pcm_native.c:2264
> [<     inline     >] snd_pcm_oss_open_file sound/core/oss/pcm_oss.c:2342
> [<      none      >] snd_pcm_oss_open.part.17+0x5a4/0x1110
> sound/core/oss/pcm_oss.c:2424
> [<      none      >] snd_pcm_oss_open+0x35/0x50 sound/core/oss/pcm_oss.c:2388
> [<      none      >] soundcore_open+0x30f/0x640 sound/sound_core.c:639
> [<      none      >] chrdev_open+0x22a/0x4c0 fs/char_dev.c:388
> [<      none      >] do_dentry_open+0x6a2/0xcb0 fs/open.c:736
> [<      none      >] vfs_open+0x17b/0x1f0 fs/open.c:853
> [<     inline     >] do_last fs/namei.c:3254
> [<      none      >] path_openat+0xde9/0x5e30 fs/namei.c:3386
> [<      none      >] do_filp_open+0x18e/0x250 fs/namei.c:3421
> [<      none      >] do_sys_open+0x1fc/0x420 fs/open.c:1022
> [<     inline     >] SYSC_open fs/open.c:1040
> [<      none      >] SyS_open+0x2d/0x40 fs/open.c:1035
> 
> INFO: Slab 0xffffea0001819e00 objects=24 used=20 fp=0xffff8800606799f0
> flags=0x5fffc0000004080
> INFO: Object 0xffff88006067a980 @offset=10624 fp=0x          (null)
> CPU: 2 PID: 5841 Comm: syz-executor Tainted: G    B           4.5.0-rc1+ #291
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  00000000ffffffff ffff8800316af4c8 ffffffff829e798d ffff88003e804c00
>  ffff88006067a980 ffff880060678000 ffff8800316af4f8 ffffffff8175b394
>  ffff88003e804c00 ffffea0001819e00 ffff88006067a980 0000000000008002
> 
> Call Trace:
>  [<     inline     >] kasan_report mm/kasan/report.c:274
>  [<ffffffff81764ebe>] __asan_report_store4_noabort+0x3e/0x40
> mm/kasan/report.c:299
>  [<ffffffff850dc078>] dummy_systimer_prepare+0x268/0x2a0
> sound/drivers/dummy.c:295
>  [<ffffffff850dc52b>] dummy_pcm_prepare+0x7b/0xa0 sound/drivers/dummy.c:512
>  [<ffffffff8505159a>] snd_pcm_do_prepare+0x5a/0x90 sound/core/pcm_native.c:1512
>  [<ffffffff85050886>] snd_pcm_action_single+0x76/0x120
> sound/core/pcm_native.c:944
>  [<ffffffff85050c85>] snd_pcm_action_nonatomic+0x95/0xa0
> sound/core/pcm_native.c:1011
>  [<     inline     >] snd_pcm_prepare sound/core/pcm_native.c:1552
>  [<ffffffff8505bbd5>] snd_pcm_common_ioctl1+0x1045/0x21a0
> sound/core/pcm_native.c:2765
>  [<ffffffff8505cfd2>] snd_pcm_playback_ioctl1+0x2a2/0x5e0
> sound/core/pcm_native.c:2884
>  [<ffffffff8505dad6>] snd_pcm_kernel_ioctl+0x136/0x160
> sound/core/pcm_native.c:3004
>  [<ffffffff8508bb4b>] snd_pcm_oss_prepare+0x4b/0x200
> sound/core/oss/pcm_oss.c:1112
>  [<ffffffff850941ee>] snd_pcm_oss_make_ready+0xae/0x120
> sound/core/oss/pcm_oss.c:1140
>  [<ffffffff85096d5a>] snd_pcm_oss_sync+0xba/0xa30 sound/core/oss/pcm_oss.c:1609
>  [<ffffffff8509787d>] snd_pcm_oss_release+0x1ad/0x280
> sound/core/oss/pcm_oss.c:2479
>  [<ffffffff817c0096>] __fput+0x236/0x780 fs/file_table.c:208
>  [<ffffffff817c0665>] ____fput+0x15/0x20 fs/file_table.c:244
>  [<ffffffff813b13c0>] task_work_run+0x170/0x210 kernel/task_work.c:115
>  [<     inline     >] exit_task_work include/linux/task_work.h:21
>  [<ffffffff8135ca55>] do_exit+0x8b5/0x2cb0 kernel/exit.c:748
>  [<ffffffff8135efc8>] do_group_exit+0x108/0x330 kernel/exit.c:878
>  [<ffffffff81382114>] get_signal+0x5e4/0x14f0 kernel/signal.c:2307
>  [<ffffffff811a0db3>] do_signal+0x83/0x1c90 arch/x86/kernel/signal.c:712
>  [<ffffffff81006685>] exit_to_usermode_loop+0x1a5/0x210
> arch/x86/entry/common.c:247
>  [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:282
>  [<ffffffff810084ea>] syscall_return_slowpath+0x2ba/0x340
> arch/x86/entry/common.c:344
>  [<ffffffff86459c22>] int_ret_from_sys_call+0x25/0x9f
> arch/x86/entry/entry_64.S:281
> 
> Memory state around the buggy address:
>  ffff88006067a900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff88006067a980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffff88006067aa00: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
>                                      ^
>  ffff88006067aa80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff88006067ab00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
> 
> 
> The timer is created by dummy_hrtimer_create as hrtimer, but then
> accessed by dummy_systimer_prepare as systimer. The root cause seems
> to be a data race on dummy->timer_ops which is reinitialized while it
> is being used already. The race in turn causes type confusion. Which
> in turn causes heap overwrite with known values.
> 
> I was able to reproduce this by working with sound devices and doing
> "echo -n N > /sys/module/snd_dummy/parameters/hrtimer" concurrently.
> But I am sure that syzkaller did not do writes to sysfs when this bug
> was triggered, not sure what altered hrtimer variable in that case. Or
> do you see any other possibilities for this issue to be triggered?

I don't see any other possibilities.

The easiest fix for this is obviously to disable the switch via
sysfs like below.  Meanwhile we may copy the ops to the runtime
instance so that it won't affect the running stream.  This can be done
for 4.6, while disabling sysfs for 4.5 and stable.


thanks,

Takashi

---
diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c
index 75b74850c005..bde33308f0d6 100644
--- a/sound/drivers/dummy.c
+++ b/sound/drivers/dummy.c
@@ -87,7 +87,7 @@ MODULE_PARM_DESC(pcm_substreams, "PCM substreams # (1-128) for dummy driver.");
 module_param(fake_buffer, bool, 0444);
 MODULE_PARM_DESC(fake_buffer, "Fake buffer allocations.");
 #ifdef CONFIG_HIGH_RES_TIMERS
-module_param(hrtimer, bool, 0644);
+module_param(hrtimer, bool, 0444);
 MODULE_PARM_DESC(hrtimer, "Use hrtimer as the timer source.");
 #endif
 

  reply	other threads:[~2016-01-28  6:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27  9:55 sound: heap out-of-bounds write in dummy_systimer_prepare Dmitry Vyukov
2016-01-27  9:55 ` Dmitry Vyukov
2016-01-28  6:38 ` Takashi Iwai [this message]
2016-01-28  6:38   ` Takashi Iwai
2016-01-28  7:15   ` Takashi Iwai
2016-01-28  7:15     ` Takashi Iwai
2016-02-06 18:26 Dmitry Vyukov
2016-02-07  8:15 ` Takashi Iwai
2016-02-07  8:15   ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hoac6mcof.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=Julia.Lawall@lip6.fr \
    --cc=alsa-devel@alsa-project.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=kcc@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=sasha.levin@oracle.com \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.