I skipped the annoying issue template since I've already confirmed what the problem is.
I have a GeForce RTX 5070 Ti that I normally pass to a vfio virtual machine. I have a boot script that binds the vfio drivers to the GPU and audio function. Recently I wanted to experiment with CUDA and installed the 595.91.07 NVIDIA Linux Open GPU Kernel drivers to load into my v6.12.100 kernel. Udev autoloaded the nvidia driver on next boot so my script was unable to bind vfio to the GPU but it did bind to the audio function. I was now running with vfio bound to audio and nvidia bound to the GPU. I got a kernel panic almost immediately after. The crash log is attached below.
The crash was caused by the function nv_audio_dynamic_power trying to access the address 000000010000001c which was not mapped.
The nv_audio_dynamic_power function starts by looking up the audio function (function 1 of the GPU slot) and calls pci_get_drvdata(audio_pci_dev) and puts the results into a struct snd_card * without first checking that the loaded driver is a sound driver. In my case the driver data was the drvdata for vfio.
The kernel module then reads out the card->devices pointer as a struct snd_device *, but it's just some random data in the vfio driver (0x0000000100000000 in this case). This random data is then dereferenced as pdev->type, causing the kernel panic (type is 0x1c in struct snd_device resulting in the fault address 000000010000001c).
The kernel module should first check that the expected snd-hda-intel driver is bound to the audio function before probing it.
I also don't see any obvious locking in the nv_audio_dynamic_power function. os_pci_init_handle will call pci_dev_put which decrements the reference count on the device before nv_audio_dynamic_power starts to access it. So what happens if the user unbinds the snd-hda-intel driver while nv_audio_dynamic_power accesses it? There is a comment in os_pci_init_handle saying "TODO: Fix me! (hotplug)," which I assume refers to this scenario.
I also guess there should be ALSA specific locking involved when accessing the parameters of snd_card and snd_device so that snd-hda-intel can't change them while nv_audio_dynamic_power is probing. A badly timed snd_card_free() might also crash the kernel?
595.91.07 is not the latest driver but the code looks the same in latest release.
BUG: unable to handle page fault for address: 000000010000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 UID: 1000 PID: 5445 Comm: akregator Tainted: G OE 6.12.100 #64
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: ASRock Z790 PG Riptide/Z790 PG Riptide, BIOS 20.01 09/24/2025
RIP: 0010:nv_audio_dynamic_power+0x99/0x100 [nvidia]
Code: 4b 48 8b 82 a8 01 00 00 48 81 c2 a0 01 00 00 c7 44 24 04 00 00 00 00 48 39 d0 75 0e eb 2e 0f 1f 00 48 8b 40 08 48 39 d0 74 22 <83> 78 1c 03 75 f1 48 8b 78 20 48 83 bf 18 03 00 00 00 74
RSP: 0018:ffffaaa6c2426f30 EFLAGS: 00010207
RAX: 0000000100000000 RBX: ffffa2581114e820 RCX: 000000000000000f
RDX: ffffa257c41b91a0 RSI: 0000000000000000 RDI: ffffa257c245c100
RBP: ffffaaa6c2426f40 R08: 0000000000000002 R09: 0000000000000000
R10: ffffaaa6c2427020 R11: 0000000020803d03 R12: ffffaaa6c2427160
R13: ffffaaa6c2427020 R14: ffffffffc1cac230 R15: ffffffffc14dc140
FS: 00007f298ff7a200(0000) GS:ffffa2868f4c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000010000001c CR3: 00000001506c4004 CR4: 0000000000f72ef0
PKRU: 55555554
Call Trace:
<TASK>
subdeviceCtrlCmdOsUnixAudioDynamicPower_IMPL+0x27/0x40 [nvidia]
? resControl_IMPL+0x1ad/0x1c0 [nvidia]
? gpuresControl_IMPL+0x50/0x90 [nvidia]
? serverControl+0x48d/0x590 [nvidia]
? os_get_monotonic_time_ns+0x29/0x80 [nvidia]
? serverControlApiCopyOut+0x8ca/0xb60 [nvidia]
? rmapiControlWithSecInfo+0x79/0x200 [nvidia]
? rmapiControlWithSecInfoTls+0x76/0x1b0 [nvidia]
? embeddedParamCopyOut+0xd04/0x1080 [nvidia]
? nvHandleHDMIFRLRetrainEventDeferredWork+0xf14/0x2620 [nvidia_modeset]
? Nv04ControlKernel+0x60/0x70 [nvidia]
? nvkms_call_rm+0x38/0x60 [nvidia_modeset]
? nvRmApiControl+0x5e/0x70 [nvidia_modeset]
? nvAssignEvoCaps+0x2b9/0x820 [nvidia_modeset]
? nvRemoveUnusedHdmiDpAudioDevice+0xc4/0xf0 [nvidia_modeset]
? nvRemoveUnusedHdmiDpAudioDevice+0x1b/0xf0 [nvidia_modeset]
? nvValidateModeForModeset+0x2c11/0x2f00 [nvidia_modeset]
? nvSetDispModeEvo+0x2104/0x40a0 [nvidia_modeset]
? nvShutDownApiHeads+0x20f/0x240 [nvidia_modeset]
? nvEvoRestoreConsole+0x1d2/0x1330 [nvidia_modeset]
? nvkms_call_rm+0x48/0x60 [nvidia_modeset]
? nvRmApiFree+0x31/0x40 [nvidia_modeset]
? kfree+0x333/0x3a0
? nvDIFRFree+0xbe/0x110 [nvidia_modeset]
? nvFreeDevEvo+0x55/0x150 [nvidia_modeset]
? nvFreePerOpenDev+0x1b7/0x240 [nvidia_modeset]
? __check_object_size+0x1fb/0x220
? nvKmsKapiSetSemaphoreSurfaceValue+0x4068/0x4ca0 [nvidia_modeset]
? nvKmsIoctl+0x103/0x2c0 [nvidia_modeset]
? nvKmsKapiUI32ToF32+0x397/0x7c0 [nvidia_modeset]
? __x64_sys_ioctl+0x92/0xc0
? do_syscall_64+0x77/0x170
? do_user_addr_fault+0x35a/0x620
? sched_clock+0xc/0x30
? get_vtime_delta+0xe/0x80
? ct_kernel_exit.isra.0+0x78/0xa0
? __ct_user_enter+0x52/0xc0
? entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Modules linked in: nvidia_modeset(OE) nvidia_uvm(OE) nvidia(OE) cmac bnep 8021q xt_MASQUERADE iptable_nat nf_nat xt_limit xt_conntrack nf_conntrack nf_defrag_ipv4 iptable_filter iptable_mangle ip_tables ath9k_htc mac80211 i915 libarc4 ath9k_common ath9k_hw btusb btrtl btintel btbcm ath btmtk bluetooth cfg80211 cdc_acm joydev rfkill snd_hda_codec_hdmi kvm_intel i2c_algo_bit drm_buddy ttm snd_hda_intel kvm snd_intel_dspcfg intel_gtt iTCO_wdt snd_hda_codec intel_pmc_bxt intel_lpss_pci intel_lpss snd_hda_core drm_display_helper r8169 polyval_clmulni polyval_generic sha256_ssse3 iTCO_vendor_support idma64 cec sha1_ssse3 sha1_generic virt_dma pcspkr
CR2: 000000010000001c
---[ end trace 0000000000000000 ]---
RIP: 0010:nv_audio_dynamic_power+0x99/0x100 [nvidia]
Code: 4b 48 8b 82 a8 01 00 00 48 81 c2 a0 01 00 00 c7 44 24 04 00 00 00 00 48 39 d0 75 0e eb 2e 0f 1f 00 48 8b 40 08 48 39 d0 74 22 <83> 78 1c 03 75 f1 48 8b 78 20 48 83 bf 18 03 00 00 00 74 0e 48 85
RSP: 0018:ffffaaa6c2426f30 EFLAGS: 00010207
RAX: 0000000100000000 RBX: ffffa2581114e820 RCX: 000000000000000f
RDX: ffffa257c41b91a0 RSI: 0000000000000000 RDI: ffffa257c245c100
RBP: ffffaaa6c2426f40 R08: 0000000000000002 R09: 0000000000000000
R10: ffffaaa6c2427020 R11: 0000000020803d03 R12: ffffaaa6c2427160
R13: ffffaaa6c2427020 R14: ffffffffc1cac230 R15: ffffffffc14dc140
FS: 00007f298ff7a200(0000) GS:ffffa2868f4c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000010000001c CR3: 00000001506c4004 CR4: 0000000000f72ef0
PKRU: 55555554
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x2d000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---
I skipped the annoying issue template since I've already confirmed what the problem is.
I have a GeForce RTX 5070 Ti that I normally pass to a vfio virtual machine. I have a boot script that binds the vfio drivers to the GPU and audio function. Recently I wanted to experiment with CUDA and installed the 595.91.07 NVIDIA Linux Open GPU Kernel drivers to load into my v6.12.100 kernel. Udev autoloaded the nvidia driver on next boot so my script was unable to bind vfio to the GPU but it did bind to the audio function. I was now running with vfio bound to audio and nvidia bound to the GPU. I got a kernel panic almost immediately after. The crash log is attached below.
The crash was caused by the function
nv_audio_dynamic_powertrying to access the address 000000010000001c which was not mapped.The
nv_audio_dynamic_powerfunction starts by looking up the audio function (function 1 of the GPU slot) and callspci_get_drvdata(audio_pci_dev)and puts the results into astruct snd_card *without first checking that the loaded driver is a sound driver. In my case the driver data was the drvdata for vfio.The kernel module then reads out the
card->devicespointer as astruct snd_device *, but it's just some random data in the vfio driver (0x0000000100000000 in this case). This random data is then dereferenced as pdev->type, causing the kernel panic (type is 0x1c instruct snd_deviceresulting in the fault address 000000010000001c).The kernel module should first check that the expected snd-hda-intel driver is bound to the audio function before probing it.
I also don't see any obvious locking in the
nv_audio_dynamic_powerfunction.os_pci_init_handlewill callpci_dev_putwhich decrements the reference count on the device beforenv_audio_dynamic_powerstarts to access it. So what happens if the user unbinds the snd-hda-intel driver whilenv_audio_dynamic_poweraccesses it? There is a comment inos_pci_init_handlesaying "TODO: Fix me! (hotplug)," which I assume refers to this scenario.I also guess there should be ALSA specific locking involved when accessing the parameters of
snd_cardandsnd_deviceso that snd-hda-intel can't change them whilenv_audio_dynamic_poweris probing. A badly timedsnd_card_free()might also crash the kernel?595.91.07 is not the latest driver but the code looks the same in latest release.