Wind River Support Network

Description

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