In the Linux kernel, the following vulnerability has been resolved:
comedi: check device's attached status in compat ioctls
Syzbot identified an issue [1] that crashes kernel, seemingly due to unexistent callback dev->getvalidroutes(). By all means, this should not occur as said callback must always be set to getzerovalidroutes() in _comedidevicepostconfig().
As the crash seems to appear exclusively in i386 kernels, at least, judging from [1] reports, the blame lies with compat versions of standard IOCTL handlers. Several of them are modified and do not use comediunlockedioctl(). While functionality of these ioctls essentially copy their original versions, they do not have required sanity check for device's attached status. This, in turn, leads to a possibility of calling select IOCTLs on a device that has not been properly setup, even via COMEDI_DEVCONFIG.
Doing so on unconfigured devices means that several crucial steps are missed, for instance, specifying dev->getvalidroutes() callback.
Fix this somewhat crudely by ensuring device's attached status before performing any ioctls, improving logic consistency between modern and compat functions.
[1] Syzbot report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0 Call Trace: <TASK> getvalidroutes drivers/comedi/comedifops.c:1322 [inline] parseinsn+0x78c/0x1970 drivers/comedi/comedifops.c:1401 doinsnlistioctl+0x272/0x700 drivers/comedi/comedifops.c:1594 compatinsnlist drivers/comedi/comedifops.c:3208 [inline] comedicompatioctl+0x810/0x990 drivers/comedi/comedifops.c:3273 _docompatsysioctl fs/ioctl.c:695 [inline] _secompatsysioctl fs/ioctl.c:638 [inline] _ia32compatsysioctl+0x242/0x370 fs/ioctl.c:638 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] ...
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68257.json",
"cna_assigner": "Linux"
}