CVE-2025-68258

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: multiq3: sanitize config options in multiq3_attach()<br /> <br /> Syzbot identified an issue [1] in multiq3_attach() that induces a<br /> task timeout due to open() or COMEDI_DEVCONFIG ioctl operations,<br /> specifically, in the case of multiq3 driver.<br /> <br /> This problem arose when syzkaller managed to craft weird configuration<br /> options used to specify the number of channels in encoder subdevice.<br /> If a particularly great number is passed to s-&gt;n_chan in<br /> multiq3_attach() via it-&gt;options[2], then multiple calls to<br /> multiq3_encoder_reset() at the end of driver-specific attach() method<br /> will be running for minutes, thus blocking tasks and affected devices<br /> as well.<br /> <br /> While this issue is most likely not too dangerous for real-life<br /> devices, it still makes sense to sanitize configuration inputs. Enable<br /> a sensible limit on the number of encoder chips (4 chips max, each<br /> with 2 channels) to stop this behaviour from manifesting.<br /> <br /> [1] Syzbot crash:<br /> INFO: task syz.2.19:6067 blocked for more than 143 seconds.<br /> ...<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5254 [inline]<br /> __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862<br /> __schedule_loop kernel/sched/core.c:6944 [inline]<br /> schedule+0x165/0x360 kernel/sched/core.c:6959<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016<br /> __mutex_lock_common kernel/locking/mutex.c:676 [inline]<br /> __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760<br /> comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868<br /> chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414<br /> do_dentry_open+0x953/0x13f0 fs/open.c:965<br /> vfs_open+0x3b/0x340 fs/open.c:1097<br /> ...