drivers/comedi/comedi_fops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a5e45f768aab5892da5d
Tested-by: syzbot+a5e45f768aab5892da5d@syzkaller.appspotmail.com
Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com>
---
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;
--
2.43.0
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@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=a5e45f768aab5892da5d > Tested-by: syzbot+a5e45f768aab5892da5d@syzkaller.appspotmail.com > Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com> > --- > 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. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
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@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=a5e45f768aab5892da5d >> Tested-by: syzbot+a5e45f768aab5892da5d@syzkaller.appspotmail.com >> Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com> >> --- >> 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. >
On 25/07/2025 10:43, Lecomte, Arnaud wrote: > 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. Actually, I'm just building a (hopefully) fixed version at the moment. I'll add you to the Cc list for it. > 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@syzkaller.appspotmail.com >>> Closes: https://syzkaller.appspot.com/bug?extid=a5e45f768aab5892da5d >>> Tested-by: syzbot+a5e45f768aab5892da5d@syzkaller.appspotmail.com >>> Signed-off-by: Arnaud Lecomte <contact@arnaud-lcm.com> >>> --- >>> 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. >> -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-
Thanks Ian ! Keep me in touch on how it is going or if you need my help at any moment. On 25/07/2025 11:04, Ian Abbott wrote: > > Actually, I'm just building a (hopefully) fixed version at the moment. > I'll add you to the Cc list for it.
© 2016 - 2025 Red Hat, Inc.