ADLP_RVP_SDW failed with KASAN slab-out-of-bounds in hdac_hda_dai_hw_params
KASAN report this error right after simple playback. Weekly report started to report this failure from a month ago. The reason why I hold this issue is that I couldn't reproduce the problem with same build manually. I couldn't reproduce with last week's recipe also but instead of holding it with me, submitting the issue first and I will find out what I might miss.
CMD: TPLG=/lib/firmware/intel/sof-tplg/sof-adl-rt711-4ch.tplg MODEL=ADLP_RVP_SDW_ZEPHYR ~/sof-test/test-case/check-playback.sh -d 10 -l 1 -r 1
- Kernel Branch: topic/sof-dev
- Kernel Commit: 592a3f2a with kasan enabled kconfig
- SOF Branch: main
- SOF Commit: [25493e5d44fe] (https://github.com/thesofproject/sof/commit/25493e5d44fe)
Internal test link: 17605?model=ADLP_RVP_SDW_ZEPHYR&testcase=check-playback-10sec
===========================>>
[ 464.719339] kernel: ==================================================================
[ 464.719389] kernel: BUG: KASAN: slab-out-of-bounds in hdac_hda_dai_hw_params+0x142/0x1a0 [snd_soc_hdac_hda]
[ 464.719431] kernel: Write of size 4 at addr ffff88810cbce0a0 by task aplay/2875
[ 464.719462] kernel:
[ 464.719472] kernel: CPU: 4 PID: 2875 Comm: aplay Tainted: G U 6.1.0-rc1-weekly-kasan-default-20221112-g592a3f2a6456 #kconfig
[ 464.719525] kernel: Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021
[ 464.719580] kernel: Call Trace:
[ 464.719593] kernel:
[ 464.719606] kernel: dump_stack_lvl+0x34/0x48
[ 464.719629] kernel: print_report+0x155/0x48c
[ 464.719650] kernel: ? __virt_addr_valid+0xf1/0x170
[ 464.719673] kernel: ? __phys_addr+0x40/0x80
[ 464.719692] kernel: ? kasan_addr_to_slab+0x4a/0x90
[ 464.719716] kernel: ? hdac_hda_dai_hw_params+0x142/0x1a0 [snd_soc_hdac_hda]
[ 464.719749] kernel: kasan_report+0x95/0x150
[ 464.719770] kernel: ? hdac_hda_dai_hw_params+0x142/0x1a0 [snd_soc_hdac_hda]
[ 464.719804] kernel: hdac_hda_dai_hw_params+0x142/0x1a0 [snd_soc_hdac_hda]
[ 464.719839] kernel: snd_soc_dai_hw_params+0x9a/0x100 [snd_soc_core]
[ 464.719905] kernel: ? snd_soc_link_hw_params+0xe3/0x100 [snd_soc_core]
[ 464.719966] kernel: __soc_pcm_hw_params+0x5e1/0xa90 [snd_soc_core]
[ 464.720028] kernel: ? soc_pcm_open+0x90/0x90 [snd_soc_core]
[ 464.720087] kernel: ? lock_release+0x262/0x6f0
[ 464.720109] kernel: ? _lookup_address_cpa.isra.0+0x70/0x70
[ 464.720134] kernel: ? __fentry__+0x10/0x10
[ 464.720165] kernel: ? memset+0x20/0x50
[ 464.720184] kernel: ? sof_ipc3_pcm_dai_link_fixup+0x769/0xe10 [snd_sof]
[ 464.720241] kernel: ? sof_pcm_dai_link_fixup+0xb9/0x110 [snd_sof]
[ 464.720293] kernel: dpcm_be_dai_hw_params+0x224/0x4a0 [snd_soc_core]
[ 464.720355] kernel: ? dpcm_fe_dai_hw_free+0x120/0x120 [snd_soc_core]
[ 464.720426] kernel: ? wait_for_completion_io+0x260/0x260
[ 464.720452] kernel: ? dpcm_set_fe_update_state+0x56/0x110 [snd_soc_core]
[ 464.720514] kernel: ? dpcm_set_fe_update_state+0xc3/0x110 [snd_soc_core]
[ 464.720576] kernel: dpcm_fe_dai_hw_params+0x9e/0x250 [snd_soc_core]
[ 464.720637] kernel: snd_pcm_hw_params+0x5ca/0xbe0 [snd_pcm]
[ 464.720680] kernel: ? do_raw_spin_unlock+0xa3/0x140
[ 464.720703] kernel: ? snd_pcm_release+0x110/0x110 [snd_pcm]
[ 464.720742] kernel: ? _raw_spin_unlock_irqrestore+0x33/0x60
[ 464.720768] kernel: ? __might_sleep+0x27/0xb0
[ 464.720789] kernel: ? __might_resched+0xf1/0x110
[ 464.720810] kernel: ? __might_fault+0x39/0x50
[ 464.720831] kernel: ? _copy_from_user+0x94/0xc0
[ 464.720855] kernel: snd_pcm_common_ioctl+0x23b/0x16a0 [snd_pcm]
[ 464.720896] kernel: ? __might_sleep+0x27/0xb0
[ 464.720916] kernel: ? __might_resched+0xf1/0x110
[ 464.720939] kernel: ? snd_pcm_status_user32+0x280/0x280 [snd_pcm]
[ 464.720981] kernel: ? selinux_ip_output+0xb0/0xb0
[ 464.721003] kernel: ? schedstat_start+0x51/0xa0
[ 464.721025] kernel: ? down_read_nested+0x4b0/0x4b0
[ 464.721047] kernel: ? handle_mm_fault+0x11c/0x240
[ 464.721071] kernel: snd_pcm_ioctl+0x47/0x60 [snd_pcm]
[ 464.721109] kernel: __x64_sys_ioctl+0xba/0x100
[ 464.721131] kernel: do_syscall_64+0x38/0x90
[ 464.721151] kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 464.721177] kernel: RIP: 0033:0x7f2d8cd29aff
[ 464.721196] kernel: Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00
[ 464.721274] kernel: RSP: 002b:00007ffe90177aa0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 464.721310] kernel: RAX: ffffffffffffffda RBX: 00007ffe90177c90 RCX: 00007f2d8cd29aff
[ 464.721343] kernel: RDX: 00007ffe90177c90 RSI: 00000000c2604111 RDI: 0000000000000004
[ 464.721376] kernel: RBP: 000055ea6b3b67d0 R08: 0000000000000000 R09: 0000000000000000
[ 464.721407] kernel: R10: 0000000000000004 R11: 0000000000000246 R12: 000055ea6b3b6750
[ 464.721439] kernel: R13: 00007ffe90177c00 R14: 000000000000bb80 R15: 000000000000bb80
[ 464.721474] kernel:
[ 464.721487] kernel:
[ 464.721496] kernel: Allocated by task 17:
[ 464.721613] kernel:
[ 464.721622] kernel: Last potentially related work creation:
[ 464.721680] kernel:
[ 464.721689] kernel: Second to last potentially related work creation:
[ 464.721747] kernel:
[ 464.721756] kernel: The buggy address belongs to the object at ffff88810cbce008
which belongs to the cache kmalloc-192 of size 192
[ 464.721809] kernel: The buggy address is located 152 bytes inside of
192-byte region [ffff88810cbce008, ffff88810cbce0c8)
[ 464.721859] kernel:
[ 464.721869] kernel: The buggy address belongs to the physical page:
[ 464.721912] kernel:
[ 464.721922] kernel: Memory state around the buggy address:
[ 464.721945] kernel: ffff88810cbcdf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 464.721977] kernel: ffff88810cbce000: fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 464.722010] kernel: >ffff88810cbce080: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
[ 464.722042] kernel: ^
[ 464.722063] kernel: ffff88810cbce100: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
[ 464.722096] kernel: ffff88810cbce180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 464.722128] kernel: ==================================================================
<<===========================
thanks for filing this @fredoh9, we are reworking this code at the moment so we should take a look. @RanderWang @ranj063 @jsarha @ujfalusi FYI
Actually no, this happens in sound/soc/codecs/hdac_hda.c, and there was recently a commit to fix an invalid access. See
37882100cd0629d830db430a8cee0b724fe1fea3 "ASoC: hdac_hda: fix hda pcm buffer overflow"
From the trace in the commit message it looks to be the same problem
@fredoh9 is this something that can be reproduced?
@fredoh9 closing, I believe this was fixed. If this re-happens please re-open.