Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Cen Zhang <zzzccc427@gmail.com>
Cc: perex@perex.cz, tiwai@suse.com, phucduc.bui@gmail.com,
	kees@kernel.org, blum@kernel.org, linux-sound@vger.kernel.org,
	linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
	jjzuming@gmail.com
Subject: Re: [PATCH] ALSA: jack: Remove debugfs before freeing unregistered jacks
Date: Mon, 12 Oct 2026 09:28:15 +0200	[thread overview]
Message-ID: <871p9vidio.wl-tiwai@suse.de> (raw)
In-Reply-To: <pm-pmb-e1e7490bbe7ba1b3c44a-v2-3e3b6315a18c02ced60d@gmail.com>

On Sun, 11 Oct 2026 17:55:56 +0200,
Cen Zhang wrote:
> 
> Jack debugfs files store a raw snd_jack_kctl pointer, so their
> callbacks must be drained before the attachment is freed.
> snd_jack_dev_free() unlinks and frees the attachments before calling
> snd_jack_dev_disconnect(). Its late snd_jack_remove_debugfs() call
> then has no entries left to traverse.
> 
> With CONFIG_SND_JACK_INJECTION_DEBUG and input support enabled, an
> HDA codec rebind on a live card can publish a non-phantom jack's type
> file while its component is still in SNDRV_DEV_BUILD. A later
> jack-control allocation failure permits the following order:
> 
>   1. hda_codec_driver_probe() creates a jack and publishes its debugfs
>      files before reaching snd_card_register().
>   2. A later control-build failure calls
>      snd_hda_codec_cleanup_for_unbind(), then snd_hda_jack_tbl_clear()
>      and snd_device_free(). __snd_device_disconnect() skips BUILD
>      components. snd_jack_dev_free() frees the attachment before its
>      late disconnect, leaving the debugfs files published.
>   3. After cleanup, a reader opens the surviving type file and
>      jack_type_read() dereferences the freed attachment's jack pointer.
> 
> The card's debugfs root remains live throughout this sequence. The
> result is a use-after-free even without an overlapping read. An
> already admitted callback is also not drained by this cleanup.
> 
> Call snd_jack_remove_debugfs() before unlinking any controls in the
> free callback. The existing debugfs_remove() rundown blocks new
> accesses and waits for active callbacks while the attachment, control
> and jack remain valid. Roots cleared by an earlier disconnect are
> NULL, so repeating the removal is harmless.
> 
> KASAN report as below:
> 
>     ==================================================================
>     BUG: KASAN: slab-use-after-free in jack_type_read+0x1da/0x1f0
>     Read of size 8 at addr ffff8881085f9da0 by task python3/429
> 
>     CPU: 2 UID: 0 PID: 429 Comm: python3 Not tainted 7.2.0-rc6-pmb-alsa-functional-v2+ #1 PREEMPT(lazy)
>     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
>      ? jack_type_read+0x1da/0x1f0
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __virt_addr_valid+0x20d/0x410
>      ? jack_type_read+0x1da/0x1f0
>      kasan_report+0xe0/0x110
>      ? jack_type_read+0x1da/0x1f0
>      jack_type_read+0x1da/0x1f0
>      ? __pfx_jack_type_read+0x10/0x10
>      ? __pfx___debugfs_file_get+0x10/0x10
>      ? __pfx_cp_new_stat+0x10/0x10
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? selinux_file_permission+0x122/0x570
>      full_proxy_read+0x11f/0x180
>      ? __pfx_full_proxy_read+0x10/0x10
>      vfs_read+0x1a0/0xc20
>      ? __pfx_vfs_read+0x10/0x10
>      ? srso_alias_return_thunk+0x5/0xfbef5
>      ? __do_sys_newfstat+0xa6/0x100
>      ? find_held_lock+0x2b/0x80
>      ? __pfx___do_sys_newfstat+0x10/0x10
>      ksys_read+0x111/0x200
>      ? __pfx_ksys_read+0x10/0x10
>      ? full_proxy_llseek+0x11e/0x170
>      do_syscall_64+0x115/0x6a0
>      entry_SYSCALL_64_after_hwframe+0x77/0x7f
>     RIP: 0033:0x7f7e392e7687
>     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:00007fff5f7b9180 EFLAGS: 00000202 ORIG_RAX: 0000000000000000
>     RAX: ffffffffffffffda RBX: 00007f7e39253780 RCX: 00007f7e392e7687
>     RDX: 0000000000002000 RSI: 000000003d2e9b00 RDI: 0000000000000003
>     RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>     R10: 0000000000000000 R11: 0000000000000202 R12: 00007f7e39253700
>     R13: 0000000000002000 R14: 00007f7e38d7e2c0 R15: 0000000000a55b98
>      </TASK>
> 
>     Allocated by task 425:
>      kasan_save_stack+0x33/0x60
>      kasan_save_track+0x14/0x30
>      __kasan_kmalloc+0xaa/0xb0
>      __kmalloc_cache_noprof+0x251/0x610
>      snd_jack_kctl_new+0x80/0x180
>      snd_jack_new+0x4b/0x490
>      snd_hda_jack_add_kctl_mst+0x19b/0x610
>      add_jack_kctl+0x204/0x320
>      snd_hda_jack_add_kctls+0x212/0x910
>      snd_hda_gen_build_controls+0x233/0x600
>      snd_hda_codec_build_controls+0x2e4/0x9f0
>      hda_codec_driver_probe+0x26e/0x590
>      really_probe+0x21f/0xa90
>      __driver_probe_device+0x1ec/0x490
>      device_driver_attach+0xdc/0x210
>      bind_store+0xec/0x180
>      drv_attr_store+0x79/0xb0
>      sysfs_kf_write+0xed/0x140
>      kernfs_fop_write_iter+0x34b/0x500
>      vfs_write+0x637/0x1010
>      ksys_write+0x111/0x200
>      do_syscall_64+0x115/0x6a0
>      entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
>     Freed by task 425:
>      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_jack_kctl_private_free+0x153/0x200
>      __snd_ctl_remove+0x29f/0x3b0
>      snd_ctl_remove+0x46/0x70
>      snd_jack_dev_free+0x1b1/0x370
>      __snd_device_free+0x193/0x3f0
>      snd_device_free+0xcf/0x190
>      snd_hda_jack_tbl_clear+0x159/0x2e0
>      snd_hda_codec_cleanup_for_unbind+0x37e/0x9c0
>      hda_codec_driver_probe+0x3ae/0x590
>      really_probe+0x21f/0xa90
>      __driver_probe_device+0x1ec/0x490
>      device_driver_attach+0xdc/0x210
>      bind_store+0xec/0x180
>      drv_attr_store+0x79/0xb0
>      sysfs_kf_write+0xed/0x140
>      kernfs_fop_write_iter+0x34b/0x500
>      vfs_write+0x637/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 ffff8881085f9d80
>      which belongs to the cache kmalloc-64 of size 64
>     The buggy address is located 32 bytes inside of
>      freed 64-byte region [ffff8881085f9d80, ffff8881085f9dc0)
> 
>     The buggy address belongs to the physical page:
>     page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1085f9
>     flags: 0x200000000000000(node=0|zone=2)
>     page_type: f5(slab)
>     raw: 0200000000000000 ffff8881000428c0 dead000000000100 dead000000000122
>     raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000
>     page dumped because: kasan: bad access detected
> 
>     Memory state around the buggy address:
>      ffff8881085f9c80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
>      ffff8881085f9d00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>     >ffff8881085f9d80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>                                    ^
>      ffff8881085f9e00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>      ffff8881085f9e80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>     ==================================================================
> 
> Fixes: 495000a38634 ("ALSA: core: Remove debugfs at disconnection")
> Assisted-by: LLM
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>

Could you verify whether the problem still exists with the latest
sound.git tree for-next branch (i.e. for 7.4)?  There have been fixes
for the races at the disconnection, and snd_card_disconnect() became
already mandatory before the release.


thanks,

Takashi

  reply	other threads:[~2026-10-12  7:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 15:55 [PATCH] ALSA: jack: Remove debugfs before freeing unregistered jacks Cen Zhang
2026-10-12  7:28 ` Takashi Iwai [this message]
2026-10-13  4:21   ` Cen Zhang
2026-10-13  6:57     ` 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=871p9vidio.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=baijiaju1990@gmail.com \
    --cc=blum@kernel.org \
    --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=phucduc.bui@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox