UBUNTU-CVE-2026-23017: Null Pointer Dereference

In the Linux kernel, the following vulnerability has been resolved: idpf: fix error handling in the inittask on load If the inittask fails during a driver load, we end up without vports and netdevs, effectively failing the entire process. In that state a subsequent reset will result in a crash as the service task attempts to access uninitialized resources. Following trace is from an error in the inittask where the CREATEVPORT (op 501) is rejected by the FW: [40922.763136] idpf 0000:83:00.0: Device HW Reset initiated [40924.449797] idpf 0000:83:00.0: Transaction failed (op 501) [40958.148190] idpf 0000:83:00.0: HW reset detected [40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8 ... [40958.168094] Workqueue: idpf-0000:83:00.0-vcevent idpfvceventtask [idpf] [40958.168865] RIP: 0010:idpfvceventtask+0x9b/0x350 [idpf] ... [40958.177932] Call Trace: [40958.178491] <TASK> [40958.179040] processonework+0x226/0x6d0 [40958.179609] workerthread+0x19e/0x340 [40958.180158] ? pfxworkerthread+0x10/0x10 [40958.180702] kthread+0x10f/0x250 [40958.181238] ? pfxkthread+0x10/0x10 [40958.181774] retfromfork+0x251/0x2b0 [40958.182307] ? pfxkthread+0x10/0x10 [40958.182834] retfromforkasm+0x1a/0x30 [40958.183370] </TASK> Fix the error handling in the inittask to make sure the service and mailbox tasks are disabled if the error happens during load. These are started in idpfvccoreinit(), which spawns the inittask and has no way of knowing if it failed. If the error happens on reset, following successful driver load, the tasks can still run, as that will allow the netdevs to attempt recovery through another reset. Stop the PTP callbacks either way as those will be restarted by the call to idpfvccoreinit() during a successful reset.