CVE-2026-74472: ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev()

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.