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

On Tue, Jul 26, 2022 at 11:41 PM Dipanjan Das mail.dipanjan.das@gmail.com wrote:

On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai tiwai@suse.de wrote:

...

On Sat, 23 Jul 2022 09:00:08 +0200, Greg KH wrote:

...

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.

Here is our analysis of the bug in the kernel v5.10.131.

During allocation, the `size` of the DMA buffer is not page-aligned: https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149. However, in sound/core/pcm_native.c:798 (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L7...), the `size` variable is page-aligned before memset-ing the `dma_area`. From the other BUG_ON assertions in other parts of the code, it looks like the DMA area is not supposed to be equal to or greater than 0x200000 bytes. However, due to page-alignment, the `size` can indeed get rounded up to 0x200000 which causes the out of bound access.

...

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.

The bug is not reproducible on the latest mainline, because in sound/core/memalloc.c:66 (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3...) the allocation function `snd_dma_alloc_dir_pages()` now page-aligns the `size` right before allocating the DMA buffer. Therefore, any subsequent page-alignment, like the one in `snd_pcm_hw_params()` does not cause an out of bound access.

Great analysis!

Now, you would just need to identify the specific commit in the mainline repository, where 'function `snd_dma_alloc_dir_pages()` now page-aligns the `size` right before allocating the DMA buffer.', and then ask for applying that commit to the v5.10 stable branch, following the guide from https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html. Greg KH and Sasha Levin are then going to let you know if that works or needs rework to backport.

Lukas

On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai tiwai@suse.de wrote:

Thanks for the analysis. A good news is that, at least for the vmalloc() case, it's a kind of false-positive; vmalloc() always takes the full pages, so practically seen, the size is page-aligned. It's fooling the memory checker, though.

But the similar problem could be seen with genalloc calls, and this was fixed by the upstream commit 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e ALSA: memalloc: Align buffer allocations in page size

I suppose you can simply backport this commit to 5.10.y. Could you confirm that this fixes your problem?

We confirm that the patch you proposed fixes the problem (blocks the reproducer). How do we proceed with getting the issue fixed? Do we send a patch according to the steps detailed here: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

On Thu, Jul 28, 2022 at 04:24:12PM -0700, Dipanjan Das wrote:

On Tue, Jul 26, 2022 at 10:25 PM Takashi Iwai tiwai@suse.de wrote:

...

Thanks for the analysis. A good news is that, at least for the vmalloc() case, it's a kind of false-positive; vmalloc() always takes the full pages, so practically seen, the size is page-aligned. It's fooling the memory checker, though.

But the similar problem could be seen with genalloc calls, and this was fixed by the upstream commit 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e ALSA: memalloc: Align buffer allocations in page size

I suppose you can simply backport this commit to 5.10.y. Could you confirm that this fixes your problem?

We confirm that the patch you proposed fixes the problem (blocks the reproducer). How do we proceed with getting the issue fixed? Do we send a patch according to the steps detailed here: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?

Normally, yes, that is the correct process. But as Takashi mentioned, I already picked it up as I happened to see this thread.

thanks,

greg k-h