Hi Ian,
Thanks for the feedback, I can send the revision of the patch by the end of the day if it is fine for you.
On 25/07/2025 10:41, Ian Abbott wrote:
On 24/07/2025 22:04, Arnaud Lecomte wrote:
KMSAN reported a kernel-infoleak when copying instruction data back to
userspace in do_insnlist_ioctl(). The issue occurs because allocated
memory buffers weren't properly initialized (not
zero initialized) before being copied to
userspace, potentially leaking kernel memory.
Reported-by: syzbot+a5e45f768aab5892da5d@xxxxxxxxxxxxxxxxxxxxxxxxx
Closes: https://syzkaller.appspot.com/bug?extid=a5e45f768aab5892da5d
Tested-by: syzbot+a5e45f768aab5892da5d@xxxxxxxxxxxxxxxxxxxxxxxxx
Signed-off-by: Arnaud Lecomte <contact@xxxxxxxxxxxxxx>
---
drivers/comedi/comedi_fops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/comedi/comedi_fops.c b/drivers/comedi/comedi_fops.c
index c83fd14dd7ad..15fee829d14c 100644
--- a/drivers/comedi/comedi_fops.c
+++ b/drivers/comedi/comedi_fops.c
@@ -1636,7 +1636,7 @@ static int do_insn_ioctl(struct comedi_device *dev,
n_data = MAX_SAMPLES;
}
- data = kmalloc_array(n_data, sizeof(unsigned int), GFP_KERNEL);
+ data = kcalloc(n_data, sizeof(unsigned int), GFP_KERNEL);
if (!data) {
ret = -ENOMEM;
goto error;
I thought my commit 46d8c744136c ("comedi: Fix initialization of data for instructions that write to subdevice" would have fixed this as long as all the driver code was playing nicely, but it seems I was mistaken.
I don't think it is necessary to use kcalloc(). The buffer already gets initialized (partly by `copy_from_user()`) when `insn->insn & INSN_MASK_WRITE` is non-zero, so it just needs to be initialized when `insn->insn & INSN_MASK_WRITE` is zero too.
There is nearly identical code in `do_insnlist_ioctl()` that needs fixing, so it would be better to fix both at the same time.