[PATCH 0/2] staging: vc04_services: vc-sm-cma: fix security issues in clean_invalid2 ioctl

[PATCH 0/2] staging: vc04_services: vc-sm-cma: fix security issues in clean_invalid2 ioctl

[Sebastian Josue Alba Vives]

This series fixes two security issues in the VideoCore shared memory CMA
driver (vc-sm-cma), accessible via /dev/vc-sm-cma which is created with
mode 0666 (world-accessible, no authentication required).

Both bugs are in vc_sm_cma_clean_invalid2(), reachable via the
VC_SM_CMA_CMD_CLEAN_INVALID2 ioctl on 32-bit ARM kernels.

Patch 1: Integer overflow in kmalloc size computation
Patch 2: Missing address validation in cache maintenance operations

Both issues affect 32-bit Raspberry Pi kernels (RPi 1/2/3/Zero and
32-bit RPi 4/5 configurations) running the rpi-6.6.y kernel series.

Both issues were found through manual source code auditing.

I would like to request separate CVE assignments for each patch as they
are independent vulnerabilities.

Reported-by: Sebastián Alba Vives <sebasjosue84@gmail.com>

[PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()

[Sebastian Josue Alba Vives]

From: Sebastián Alba Vives <sebasjosue84@gmail.com>

vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
compute the allocation size passed to kmalloc(). Since ioparam.op_count
is a __u32 supplied directly by userspace via ioctl, an attacker can
choose a value that causes the multiplication to overflow on 32-bit
platforms, resulting in a small allocation followed by a large
copy_from_user() and out-of-bounds heap reads in the subsequent loop.

Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
Also add an early return for op_count == 0 to avoid a zero-size
allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
correctly indicate out of memory.

The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
reachable by any unprivileged local user.

Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
 drivers/staging/vc04_services/vc-sm-cma/vc_sm.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
index 34155d62a..d597d41b4 100644
--- a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
+++ b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
@@ -1292,9 +1292,13 @@ static int vc_sm_cma_clean_invalid2(unsigned int cmdnr, unsigned long arg)
 		       __func__, cmdnr);
 		return -EFAULT;
 	}
-	block = kmalloc(ioparam.op_count * sizeof(*block), GFP_KERNEL);
+
+	if (!ioparam.op_count)
+		return 0;
+
+	block = kmalloc_array(ioparam.op_count, sizeof(*block), GFP_KERNEL);
 	if (!block)
-		return -EFAULT;
+		return -ENOMEM;
 
 	if (copy_from_user(block, (void *)(arg + sizeof(ioparam)),
 			   ioparam.op_count * sizeof(*block)) != 0) {
-- 
2.43.0

[PATCH 2/2] staging: vc04_services: vc-sm-cma: add address validation in clean_invalid_contig_2d()

[Sebastian Josue Alba Vives]

From: Sebastián Alba Vives <sebasjosue84@gmail.com>

clean_invalid_contig_2d() performs cache maintenance operations
(dmac_inv_range, dmac_clean_range, dmac_flush_range) on a user-supplied
virtual address without verifying that it falls within the user address
space. A local attacker can pass a kernel virtual address via the
VC_SM_CMA_CMD_CLEAN_INVALID2 ioctl, causing the kernel to execute cache
maintenance operations on arbitrary kernel memory, potentially leading
to data corruption or information disclosure.

Add access_ok() validation to verify the entire address range falls
within userspace before performing any cache operations. Also add
overflow checks using check_mul_overflow()/check_add_overflow() for the
range computation to prevent size_t wraparound.

The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
reachable by any unprivileged local user on 32-bit Raspberry Pi
kernels.

Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
Signed-off-by: Sebastián Alba Vives <sebasjosue84@gmail.com>
---
 .../staging/vc04_services/vc-sm-cma/vc_sm.c   | 21 ++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
index d597d41b4..29aa5a939 100644
--- a/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
+++ b/drivers/staging/vc04_services/vc-sm-cma/vc_sm.c
@@ -40,6 +40,7 @@
 #include <linux/module.h>
 #include <linux/mm.h>
 #include <linux/of_device.h>
+#include <linux/overflow.h>
 #include <linux/platform_device.h>
 #include <linux/proc_fs.h>
 #include <linux/slab.h>
@@ -1263,6 +1264,8 @@ static int clean_invalid_contig_2d(const void __user *addr,
 				   const unsigned int cache_op)
 {
 	size_t i;
+	size_t last_block_offset;
+	size_t total_range;
 	void (*op_fn)(const void *start, const void *end);
 
 	if (!block_size) {
@@ -1270,11 +1273,27 @@ static int clean_invalid_contig_2d(const void __user *addr,
 		return -EINVAL;
 	}
 
+	if (!block_count)
+		return 0;
+
 	op_fn = cache_op_to_func(cache_op);
 	if (!op_fn)
 		return -EINVAL;
 
-	for (i = 0; i < block_count; i ++, addr += stride)
+	/*
+	 * Validate that the entire user-supplied address range falls
+	 * within userspace. Without this check, an attacker could
+	 * invoke cache maintenance operations on kernel addresses.
+	 */
+	if (check_mul_overflow((size_t)(block_count - 1), stride,
+			       &last_block_offset))
+		return -EOVERFLOW;
+	if (check_add_overflow(last_block_offset, block_size, &total_range))
+		return -EOVERFLOW;
+	if (!access_ok(addr, total_range))
+		return -EFAULT;
+
+	for (i = 0; i < block_count; i++, addr += stride)
 		op_fn(addr, addr + block_size);
 
 	return 0;
-- 
2.43.0

Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()

[Greg Kroah-Hartman]

On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
> From: Sebastián Alba Vives <sebasjosue84@gmail.com>
> 
> vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
> compute the allocation size passed to kmalloc(). Since ioparam.op_count
> is a __u32 supplied directly by userspace via ioctl, an attacker can
> choose a value that causes the multiplication to overflow on 32-bit
> platforms, resulting in a small allocation followed by a large
> copy_from_user() and out-of-bounds heap reads in the subsequent loop.
> 
> Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
> Also add an early return for op_count == 0 to avoid a zero-size
> allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
> correctly indicate out of memory.

Why not use kmalloc_array() instead?

> 
> The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
> reachable by any unprivileged local user.
> 
> Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")

I do not see that git id anywhere, what tree is it in?

thanks,

greg k-h

Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()

[Sebastián Alba]

Hi Greg, Thanks for the quick review.

Regarding kmalloc_array(): the patch does replace kmalloc() with
kmalloc_array() - perhaps the question is about the remaining
ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
That multiplication is now safe because kmalloc_array() already
verified that op_count * sizeof(*block) does not overflow(if it did,
kmalloc_array would have returned NULL and we'd have exited). Happy to
add a comment clarifying this if you prefer.

Regarding the Fixes tag: the commit dfdc7a773374 is from the
raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
appears to only exist in the Raspberry Pi kernel fork and has not been
merged into mainline staging.

I apologize for sending this to the wrong tree. Should these patches
go directly to the Raspberry Pi kernel maintainers
(kernel-list@raspberrypi.com) instead?


El dom, 29 mar 2026 a las 0:33, Greg Kroah-Hartman
(<gregkh@linuxfoundation.org>) escribió:
>
> On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
> > From: Sebastián Alba Vives <sebasjosue84@gmail.com>
> >
> > vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
> > compute the allocation size passed to kmalloc(). Since ioparam.op_count
> > is a __u32 supplied directly by userspace via ioctl, an attacker can
> > choose a value that causes the multiplication to overflow on 32-bit
> > platforms, resulting in a small allocation followed by a large
> > copy_from_user() and out-of-bounds heap reads in the subsequent loop.
> >
> > Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
> > Also add an early return for op_count == 0 to avoid a zero-size
> > allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
> > correctly indicate out of memory.
>
> Why not use kmalloc_array() instead?
>
> >
> > The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
> > reachable by any unprivileged local user.
> >
> > Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
>
> I do not see that git id anywhere, what tree is it in?
>
> thanks,
>
> greg k-h



-- 
Sebastián Alba

Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()

[Greg Kroah-Hartman]

On Sun, Mar 29, 2026 at 01:04:54AM -0600, Sebastián Alba wrote:
> Hi Greg, Thanks for the quick review.
> 
> Regarding kmalloc_array(): the patch does replace kmalloc() with
> kmalloc_array() - perhaps the question is about the remaining
> ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
> That multiplication is now safe because kmalloc_array() already
> verified that op_count * sizeof(*block) does not overflow(if it did,
> kmalloc_array would have returned NULL and we'd have exited). Happy to
> add a comment clarifying this if you prefer.


Sorry, my fault, I meant alloc_objs(), coffee hadn't kicked in yet.

And please do not top-post:

	A: http://en.wikipedia.org/wiki/Top_post
	Q: Were do I find info about this thing called top-posting?
	A: Because it messes up the order in which people normally read text.
	Q: Why is top-posting such a bad thing?
	A: Top-posting.
	Q: What is the most annoying thing in e-mail?

	A: No.
	Q: Should I include quotations after my reply?

	http://daringfireball.net/2007/07/on_top

> Regarding the Fixes tag: the commit dfdc7a773374 is from the
> raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
> appears to only exist in the Raspberry Pi kernel fork and has not been
> merged into mainline staging.

Then we can't do anything with it here :(

> I apologize for sending this to the wrong tree. Should these patches
> go directly to the Raspberry Pi kernel maintainers
> (kernel-list@raspberrypi.com) instead?

No idea how that out-of-tree driver is managed, sorry.

good luck,

greg k-h

Re: [PATCH 1/2] staging: vc04_services: vc-sm-cma: fix integer overflow in vc_sm_cma_clean_invalid2()

[Sebastián Alba]

Hi Phil,

Thanks for the pointer. I've opened PR #7294 against rpi-6.6.y:
https://github.com/raspberrypi/linux/pull/7294

Sebastián

El dom, 29 mar 2026 a las 2:51, Phil Elwell (<phil@raspberrypi.com>) escribió:
>
>
>
> On Sun, 29 Mar 2026, 08:05 Sebastián Alba, <sebasjosue84@gmail.com> wrote:
>>
>> Hi Greg, Thanks for the quick review.
>>
>> Regarding kmalloc_array(): the patch does replace kmalloc() with
>> kmalloc_array() - perhaps the question is about the remaining
>> ioparam.op_count * sizeof(*block) in the copy_from_user() call below?
>> That multiplication is now safe because kmalloc_array() already
>> verified that op_count * sizeof(*block) does not overflow(if it did,
>> kmalloc_array would have returned NULL and we'd have exited). Happy to
>> add a comment clarifying this if you prefer.
>>
>> Regarding the Fixes tag: the commit dfdc7a773374 is from the
>> raspberrypi/linux tree (branch rpi-6.6.y). This driver (vc-sm-cma)
>> appears to only exist in the Raspberry Pi kernel fork and has not been
>> merged into mainline staging.
>>
>> I apologize for sending this to the wrong tree. Should these patches
>> go directly to the Raspberry Pi kernel maintainers
>> (kernel-list@raspberrypi.com) instead?
>
>
> Open a Pull Request at our Linux repo:
>
> https://github com/raspberrypi/linux/
>
> Phil
>
>> El dom, 29 mar 2026 a las 0:33, Greg Kroah-Hartman
>> (<gregkh@linuxfoundation.org>) escribió:
>> >
>> > On Sun, Mar 29, 2026 at 12:18:45AM -0600, Sebastian Josue Alba Vives wrote:
>> > > From: Sebastián Alba Vives <sebasjosue84@gmail.com>
>> > >
>> > > vc_sm_cma_clean_invalid2() uses 'ioparam.op_count * sizeof(*block)' to
>> > > compute the allocation size passed to kmalloc(). Since ioparam.op_count
>> > > is a __u32 supplied directly by userspace via ioctl, an attacker can
>> > > choose a value that causes the multiplication to overflow on 32-bit
>> > > platforms, resulting in a small allocation followed by a large
>> > > copy_from_user() and out-of-bounds heap reads in the subsequent loop.
>> > >
>> > > Replace kmalloc() with kmalloc_array(), which returns NULL on overflow.
>> > > Also add an early return for op_count == 0 to avoid a zero-size
>> > > allocation, and return -ENOMEM (not -EFAULT) on allocation failure to
>> > > correctly indicate out of memory.
>> >
>> > Why not use kmalloc_array() instead?
>> >
>> > >
>> > > The /dev/vc-sm-cma device is world-accessible (mode 0666), so this is
>> > > reachable by any unprivileged local user.
>> > >
>> > > Fixes: dfdc7a773374 ("staging: vc04_services: Add new vc-sm-cma driver")
>> >
>> > I do not see that git id anywhere, what tree is it in?
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>>
>>
>> --
>> Sebastián Alba



-- 
Sebastián Alba