From: Takashi Iwai <tiwai@suse.de>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: perex@perex.cz, tiwai@suse.com, kees@kernel.org,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, jjzuming@gmail.com
Subject: Re: [PATCH] ALSA: vmaster: Protect follower lookup and setup
Date: Fri, 16 Oct 2026 10:21:44 +0200 [thread overview]
Message-ID: <87mrse5a3r.wl-tiwai@suse.de> (raw)
In-Reply-To: <pm-pmb-6c0b7e841529ddd0b21a-v2-b53dbcd593a7a4bd9582@gmail.com>
On Fri, 16 Oct 2026 04:02:29 +0200,
Cen Zhang wrote:
>
> A control selected by snd_ctl_add_followers() must remain alive until
> _snd_ctl_add_follower() has copied it and installed its wrapper. The
> lookup returns a raw pointer without retaining the control, and neither
> the short-lived list lookup lock nor the fast lookup protects later use.
>
> If a kernel client adds followers to a live virtual master while another
> client removes or replaces a published follower, the following order is
> possible, with the card and master kept alive:
>
> Follower setup Control removal
> snd_ctl_add_followers()
> snd_ctl_find_id_mixer()
> return follower
> snd_ctl_remove()
> down_write(controls_rwsem)
> __snd_ctl_remove()
> unlink follower
> snd_ctl_free_one(follower)
> up_write(controls_rwsem)
> _snd_ctl_add_follower()
> read follower->count
>
> Removal completes after lookup returns and before setup reads the
> control. Since setup holds neither controls_rwsem nor a reference, the
> count read and subsequent control copies can access freed memory.
>
> Hold controls_rwsem for writing across the lookup and follower setup.
> This prevents removal or replacement from freeing the selected control
> until wrapper installation is complete. Write ownership also excludes
> control callbacks while setup changes the callback and private fields.
>
> KASAN report as below:
>
> BUG: KASAN: slab-use-after-free in _snd_ctl_add_follower+0x452/0x520
> Read of size 4 at addr ffff888107957d50 by task loadmodule/491
>
> CPU: 3 UID: 0 PID: 491 Comm: loadmodule Tainted: G O 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)
> Tainted: [O]=OOT_MODULE
> Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> Call Trace:
> <TASK>
> dump_stack_lvl+0x93/0xd0
> print_report+0xce/0x630
> ? _snd_ctl_add_follower+0x452/0x520
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __virt_addr_valid+0x20d/0x410
> ? _snd_ctl_add_follower+0x452/0x520
> kasan_report+0xe0/0x110
> ? _snd_ctl_add_follower+0x452/0x520
> _snd_ctl_add_follower+0x452/0x520
> snd_ctl_add_followers+0x153/0x2b0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __pfx_snd_ctl_add_followers+0x10/0x10
> ? __might_fault+0x135/0x190
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __might_fault+0x14e/0x190
> ? __pfx_fixture_write+0x10/0x10 [pmbd_vmaster_fixture]
> fixture_write+0x174/0x1f0 [pmbd_vmaster_fixture]
> ? __pfx_fixture_write+0x10/0x10 [pmbd_vmaster_fixture]
> ? __pfx___might_resched+0x10/0x10
> proc_reg_write+0x1fb/0x2d0
> vfs_write+0x25a/0x1010
> ? __pfx_proc_reg_write+0x10/0x10
> ? kmem_cache_free+0x242/0x580
> ? __pfx_vfs_write+0x10/0x10
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? putname+0x93/0xe0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_sys_openat2+0x12a/0x1b0
> ? __pfx_do_sys_openat2+0x10/0x10
> ksys_write+0x111/0x200
> ? __pfx_ksys_write+0x10/0x10
> ? irqentry_exit+0xbe/0x820
> ? srso_alias_return_thunk+0x5/0xfbef5
> do_syscall_64+0x115/0x6a0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f0b835a9687
> Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
> RSP: 002b:00007ffc82ea0360 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f0b83517780 RCX: 00007f0b835a9687
> RDX: 0000000000000005 RSI: 0000564f8a21d074 RDI: 0000000000000003
> RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
> R13: 00007ffc82ea04f0 R14: 00007f0b83755000 R15: 0000564f8a21ed78
> </TASK>
>
> Allocated by task 485:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> __kasan_kmalloc+0xaa/0xb0
> __kmalloc_noprof+0x2d7/0x770
> snd_ctl_new+0x51/0x190
> snd_ctl_new1+0x13c/0x650
> 0xffffffffc04011b5
> do_one_initcall+0xf3/0x4e0
> do_init_module+0x281/0x8e0
> load_module+0x658c/0x7cc0
> init_module_from_file+0x15b/0x180
> idempotent_init_module+0x22d/0x770
> __x64_sys_finit_module+0xd2/0x160
> do_syscall_64+0x115/0x6a0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 492:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> kasan_save_free_info+0x3b/0x60
> __kasan_slab_free+0x5f/0x80
> kfree+0x307/0x580
> __snd_ctl_remove+0x2ac/0x3d0
> snd_ctl_remove+0x46/0x70
> fixture_write+0x1ae/0x1f0 [pmbd_vmaster_fixture]
> proc_reg_write+0x1fb/0x2d0
> vfs_write+0x25a/0x1010
> ksys_write+0x111/0x200
> do_syscall_64+0x115/0x6a0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff888107957d00
> which belongs to the cache kmalloc-192 of size 192
> The buggy address is located 80 bytes inside of
> freed 192-byte region [ffff888107957d00, ffff888107957dc0)
>
> The buggy address belongs to the physical page:
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x107957
> flags: 0x200000000000000(node=0|zone=2)
> page_type: f5(slab)
> raw: 0200000000000000 ffff8881000423c0 dead000000000100 dead000000000122
> raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff888107957c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888107957c80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> >ffff888107957d00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff888107957d80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
> ffff888107957e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
> Fixes: ae07eb9bf23e ("ALSA: vmaster: Add snd_ctl_add_followers() helper")
> Assisted-by: LLM
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Applied to for-next branch. Thanks.
Takashi
prev parent reply other threads:[~2026-10-16 8:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 2:02 [PATCH] ALSA: vmaster: Protect follower lookup and setup Cen Zhang
2026-10-16 8:21 ` Takashi Iwai [this message]
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=87mrse5a3r.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=baijiaju1990@gmail.com \
--cc=jjzuming@gmail.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=zzzccc427@gmail.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.