All of lore.kernel.org
 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 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.