CVE-2025-37993

In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe The spin lock tx_handling_spinlock in struct m_can_classdev is not being initialized. This leads the following spinlock bad magic complaint from the kernel, eg. when trying to send CAN frames with cansend from can-utils: | BUG: spinlock bad magic on CPU#0, cansend/95 | lock: 0xff60000002ec1010, .magic: 00000000, .owner: /-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Hardware name: MachineWare SIM-V (DT) | Call Trace: | [ ] dump_backtrace+0x1c/0x24 | [ ] show_stack+0x28/0x34 | [ ] dump_stack_lvl+0x4a/0x68 | [ ] dump_stack+0x14/0x1c | [ ] spin_dump+0x62/0x6e | [ ] do_raw_spin_lock+0xd0/0x142 | [ ] _raw_spin_lock_irqsave+0x20/0x2c | [ ] m_can_start_xmit+0x90/0x34a | [ ] dev_hard_start_xmit+0xa6/0xee | [ ] sch_direct_xmit+0x114/0x292 | [ ] __dev_queue_xmit+0x3b0/0xaa8 | [ ] can_send+0xc6/0x242 | [ ] raw_sendmsg+0x1a8/0x36c | [ ] sock_write_iter+0x9a/0xee | [ ] vfs_write+0x184/0x3a6 | [ ] ksys_write+0xa0/0xc0 | [ ] __riscv_sys_write+0x14/0x1c | [ ] do_trap_ecall_u+0x168/0x212 | [ ] handle_exception+0x146/0x152 Initializing the spin lock in m_can_class_allocate_dev solves that problem.