Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params

[Takashi Iwai <tiwai@suse.de>]

On Sat, 23 Jul 2022 09:00:08 +0200,
Greg KH wrote:
> 
> On Fri, Jul 22, 2022 at 09:37:52AM -0700, Dipanjan Das wrote:
> > Hi,
> > 
> > We would like to report the following bug which has been found by our
> > modified version of syzkaller.
> > 
> > ======================================================
> > description: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params
> > affected file: sound/core/pcm_native.c
> > kernel version: 5.10.131
> > kernel commit: de62055f423f5dcb548f74cebd68f03c8903f73a
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=e49433cfed49b7d9
> > crash reproducer: attached
> > ======================================================
> > Crash log:
> > ======================================================
> > BUG: KASAN: vmalloc-out-of-bounds in memset include/linux/string.h:384 [inline]
> > BUG: KASAN: vmalloc-out-of-bounds in snd_pcm_hw_params+0x19b0/0x1db0
> > sound/core/pcm_native.c:799
> > Write of size 2097152 at addr ffffc900113b2000 by task syz-executor.5/14437
> > 
> > CPU: 1 PID: 14437 Comm: syz-executor.5 Tainted: G           OE     5.10.131+ #3
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.13.0-1ubuntu1.1 04/01/2014
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x107/0x163 lib/dump_stack.c:118
> >  print_address_description.constprop.0.cold+0x5/0x4f7 mm/kasan/report.c:385
> >  __kasan_report mm/kasan/report.c:545 [inline]
> >  kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
> >  check_memory_region_inline mm/kasan/generic.c:194 [inline]
> >  check_memory_region+0x187/0x1e0 mm/kasan/generic.c:200
> >  memset+0x20/0x40 mm/kasan/common.c:85
> >  memset include/linux/string.h:384 [inline]
> >  snd_pcm_hw_params+0x19b0/0x1db0 sound/core/pcm_native.c:799
> >  snd_pcm_kernel_ioctl+0xd1/0x240 sound/core/pcm_native.c:3401
> >  snd_pcm_oss_change_params_locked+0x17b6/0x3aa0 sound/core/oss/pcm_oss.c:965
> >  snd_pcm_oss_change_params+0x76/0xd0 sound/core/oss/pcm_oss.c:1107
> >  snd_pcm_oss_make_ready+0xb7/0x170 sound/core/oss/pcm_oss.c:1166
> >  snd_pcm_oss_set_trigger.isra.0+0x34f/0x770 sound/core/oss/pcm_oss.c:2074
> >  snd_pcm_oss_poll+0x679/0xb40 sound/core/oss/pcm_oss.c:2858
> >  vfs_poll include/linux/poll.h:90 [inline]
> >  do_pollfd fs/select.c:872 [inline]
> >  do_poll fs/select.c:920 [inline]
> >  do_sys_poll+0x63c/0xe40 fs/select.c:1014
> >  __do_sys_poll fs/select.c:1079 [inline]
> >  __se_sys_poll fs/select.c:1067 [inline]
> >  __x64_sys_poll+0x18c/0x490 fs/select.c:1067
> >  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x7f095de4f4ed
> > Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48
> > 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> > 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f095bdffbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000007
> > RAX: ffffffffffffffda RBX: 00007f095df6df60 RCX: 00007f095de4f4ed
> > RDX: 0000000000000009 RSI: 0000000000000001 RDI: 00000000200000c0
> > RBP: 00007f095bdffc40 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001d
> > R13: 00007ffff286ceff R14: 00007f095df6df60 R15: 00007f095bdffd80
> > 
> > 
> > Memory state around the buggy address:
> >  ffffc900115b1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >  ffffc900115b1d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >ffffc900115b1e00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >                    ^
> >  ffffc900115b1e80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> >  ffffc900115b1f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> > ==================================================================
> 
> Wondeful, do you have a fix for this that solves the reported problem
> that you have tested with the reproducer?

... or at least more detailed information.

The given log snippet alone doesn't help for further analysis, as it
doesn't show which device / driver is involved.  The code is the
common helper and the condition for the trigger might be depending on
the driver side.  The full kernel log might show which driver (IIUC,
it's /dev/adsp1) is in place.

Last but not least, you should check whether it's specific to your
5.10.x kernel or it's also seen with the latest upstream, too.


thanks,

Takashi