On 6/24/26 2:57 PM, Alvin Sun wrote: > During tyr debugfs development, a kernel NULL pointer dereference was > encountered after `rmmod tyr` while gnome-shell still held /dev/card1 open: > > ``` > [158827.868132] Unable to handle kernel NULL pointer dereference at virtual > address 0000000000000000 > [158827.868918] Mem abort info: > [158827.869177] ESR = 0x0000000086000004 > [158827.869519] EC = 0x21: IABT (current EL), IL = 32 bits > [158827.870000] SET = 0, FnV = 0 > [158827.870281] EA = 0, S1PTW = 0 > [158827.870571] FSC = 0x04: level 0 translation fault > [158827.871043] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000108dec000 > [158827.871623] [0000000000000000] pgd=0000000000000000, > p4d=0000000000000000 > [158827.872242] Internal error: Oops: 0000000086000004 [#1] SMP > [158827.872246] Modules linked in: tyr sunrpc snd_soc_simple_card > rk805_pwrkey snd_soc_simple_card_utils rtw88_8822bu display_connector > rtw88_usb rtw88_8822b snd_soc_rockchip_i2s_tdm snd_soc_hdmi_codec > rtw88_core] > [158827.872337] CPU: 4 UID: 1000 PID: 11276 Comm: gnome-s:disk$0 Tainted: G > N 7.1.0-rc1+ #331 PREEMPT > [158827.880534] Tainted: [N]=TEST > [158827.880535] Hardware name: FriendlyElec NanoPi R6C/NanoPi R6C, BIOS > v1.1 04/09/2025 > [158827.880538] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [158827.880542] pc : 0x0 > [158827.880547] lr : _RNvNtCs257m05FHVbX_3tyr2vm8pt_unmap+0x8c/0x12c [tyr] > [158827.880578] sp : ffff800083c236b0 > [158827.880579] x29: ffff800083c236d0 x28: ffff00013f8a0000 x27: > 0000000000000000 > [158827.880585] x26: 000000000000007c x25: ffff000108e6ed80 x24: > 0000000000401000 > [158827.880590] x23: 0000000000000000 x22: 0000000040000000 x21: > 0000000000001000 > [158827.880595] x20: ffff00010f778138 x19: 0000000000400000 x18: > 00000000ffffffff > [158827.880600] x17: 000000040044ffff x16: 045000f2b5503510 x15: > 0720072007200720 > [158827.880606] x14: 0720072007200720 x13: 0000000000401000 x12: > 0000000000400000 > [158827.880611] x11: ffff800083c239d0 x10: ffff000141e4fd88 x9 : > 0000000000000000 > [158827.880615] x8 : 0000000000000000 x7 : 0000000000000000 x6 : > 0000000000400000 > [158827.880620] x5 : ffff00013f8a0000 x4 : 0000000000000000 x3 : > 0000000000000001 > [158827.880625] x2 : 0000000000001000 x1 : 0000000000400000 x0 : > ffff00010f778138 > [158827.880630] Call trace: > [158827.880632] 0x0 (P) > [158827.880635] > _RNvXs6_NtCs257m05FHVbX_3tyr2vmNtB5_9GpuVmDataNtNtNtCsgmSOfgXi5CZ_6kernel3drm5gpuvm11DriverGpuVm13sm_step_unmap+0x3c/0x120 > [tyr] > [158827.891166] > _RNvMs4_NtNtNtCsgmSOfgXi5CZ_6kernel3drm5gpuvm6sm_opsINtB7_5GpuVmNtNtCs257m05FHVbX_3tyr2vm9GpuVmDataE13sm_step_unmapB13_+0x18/0x34 > [tyr] > [158827.891187] op_unmap_cb+0x78/0xb0 > [158827.891196] __drm_gpuvm_sm_unmap+0x18c/0x1b4 > [158827.891204] drm_gpuvm_sm_unmap+0x38/0x4c > [158827.891209] > _RNvMs5_NtCs257m05FHVbX_3tyr2vmNtB5_2Vm7exec_op+0x1cc/0x254 [tyr] > [158827.894085] > _RNvMs5_NtCs257m05FHVbX_3tyr2vmNtB5_2Vm11unmap_range+0x124/0x188 [tyr] > [158827.894105] > _RINvNtCs5hGKnPbRUFW_4core3ptr13drop_in_placeNtNtCs257m05FHVbX_3tyr3gem8KernelBoEBK_+0x44/0xd8 > [tyr] > [158827.894125] > _RINvNtCs5hGKnPbRUFW_4core3ptr13drop_in_placeINtNtNtCsgmSOfgXi5CZ_6kernel5alloc4kvec3VecNtNtCs257m05FHVbX_3tyr2fw7SectionNtNtBL_9allocator7KmallocEEB1r_+0x3c/0x100 > [tyr] > [158827.894147] > _RINvNtCs5hGKnPbRUFW_4core3ptr13drop_in_placeINtNtNtCsgmSOfgXi5CZ_6kernel4sync3arc3ArcNtNtCs257m05FHVbX_3tyr2fw8FirmwareEEB1p_+0x94/0x190 > [tyr] > [158827.894167] > _RNvMs4_NtNtCsgmSOfgXi5CZ_6kernel3drm6deviceINtB5_6DeviceNtNtCs257m05FHVbX_3tyr6driver12TyrDrmDriverE7releaseBW_+0x30/0x98 > [tyr] > [158827.899550] drm_dev_put.part.0+0x88/0xc0 > [158827.899557] drm_minor_release+0x18/0x28 > [158827.899562] drm_release+0x144/0x170 > [158827.899567] __fput+0xe4/0x30c > [158827.899573] ____fput+0x14/0x20 > [158827.899579] task_work_run+0x7c/0xe8 > [158827.899586] do_exit+0x2a8/0xac4 > [158827.899590] do_group_exit+0x34/0x90 > [158827.899594] get_signal+0xaac/0xabc > [158827.899599] arch_do_signal_or_restart+0x90/0x3e8 > [158827.899606] exit_to_user_mode_loop+0x140/0x1d0 > [158827.899613] el0_svc+0x2f4/0x2f8 > [158827.899620] el0t_64_sync_handler+0xa0/0xe4 > [158827.899627] el0t_64_sync+0x198/0x19c > [158827.899632] ---[ end trace 0000000000000000 ]--- > ``` > > The root cause: `fops.owner` was `NULL` in Rust DRM drivers, so the kernel > never blocked module unloading while file descriptors were open. This leads to > use-after-free when drm_release (or other fops) is called on freed module > code. > > The series moves `THIS_MODULE` into the `ModuleMetadata` as a const, threads > it > through `#[vtable]` to set `fops.owner` in DRM/miscdevice, and updates > configfs > and rnull to use `this_module::<LocalModule>()`.
I cannot comment that much on all the details of the Rust implementation, but the series looks reasonable to me from the modules perspective. I'm glad this issue will be finally addressed. I would only suggest adding the new file rust/kernel/module.rs in patch #1 under the MODULE SUPPORT support entry in the MAINTAINERS file, similarly to the other module-related Rust code, so that the module maintainers are emailed when changes to this file are proposed. I think you can change the existing 'F: rust/kernel/module_param.rs' to 'F: rust/kernel/module*.rs'. -- Thanks, Petr
