UBUNTU-CVE-2026-74472: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: ublk: reset kernel-owned devinfo fields in ublkctrladddev() ublkctrladddev() memcpy()s the userspace ublksrvctrldevinfo into ub->devinfo and then fixes up the fields the driver owns, but misses ->state and ->ublksrvpid. A device added with ->state = UBLKSDEVLIVE passes the "->state != UBLKSDEVDEAD" test that ublkstopdevunlocked() uses as its proxy for "a disk is attached", while ->ubdisk is still NULL, so DELDEV right after ADDDEV oopses in delgendisk(). UBLKSDEVQUIESCED plus UBLKFUSERRECOVERY dies one step earlier, in ublkforceabortdev(). A poisoned ->state also gets STARTUSERRECOVERY and the char device read/write path onto a device that was never started, and wedges STARTDEV at -EEXIST. A poisoned ->ublksrvpid just makes GETDEVINFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublkdetachdisk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADDDEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADDDEV, and both teardown and the STARTDEV -EEXIST check keyed off disklive() rather than ->state. The oops became reachable once the disk allocation moved to STARTDEV and those checks switched to ->state.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Configuration
In ublk_ctrl_add_dev(), reset the kernel-owned ->state and ->ublksrv_pid fields immediately after copying the userspace ublksrv_ctrl_dev_info with memcpy(), as ublk_detach_disk() does.
Linux kernel ublk ub->dev_info->state and ub->dev_info->ublksrv_pid = reset
Event History
Frequently Asked Questions
What access does an attacker need to trigger the issue?
The attacker needs to be able to submit an ADD_DEV request with crafted ublk device information. They can supply a forged state or ublksrv_pid value and then invoke follow-on ublk operations such as DEL_DEV, START_USER_RECOVERY, or START_DEV.
Which systems are in scope?
The advisory lists Ubuntu linux-riscv, linux-realtime, linux-azure, linux-gcp, linux-azure-fde, linux-gke, linux-hwe-edge, and linux-gkeop packages. Exposure depends on whether the ublk control path is available to an actor who can issue device-add requests.
What behavior could indicate attempted exploitation or an affected system?
A DEL_DEV immediately following ADD_DEV may oops in del_gendisk() when the supplied state is UBLK_S_DEV_LIVE. UBLK_S_DEV_QUIESCED with UBLK_F_USER_RECOVERY can instead fail in ublk_force_abort_dev(), while poisoned state values may wedge START_DEV with -EEXIST or permit operations against a device that was never started.