Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Integer overflow in `lsize` calculation in `udmabuf_ioctl_create_list` allows out-of-bounds heap memory access if `list_limit` is misconfigured. -- commit 0bd9a7c7e5bbe2cbc29a0cdc4dcdb2763d2b20e1 Author: Iván Ezequiel Rodriguez <[email protected]> udmabuf: reject unknown UDMABUF_CREATE flags This patch updates udmabuf_create() to reject unknown flags by checking against UDMABUF_FLAGS_CLOEXEC and returning -EINVAL. It also documents the flag semantics in udmabuf.h and adds a selftest. > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index bced421c0d658..fb36c0d9ffe72 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -358,6 +358,9 @@ static long udmabuf_create(struct miscdevice *device, > long ret = -EINVAL; > u32 i, flags; > > + if (head->flags & ~UDMABUF_FLAGS_CLOEXEC) > + return -EINVAL; > + [Severity: High] This is a pre-existing issue, but can this code trigger an out-of-bounds heap read if the list limit is misconfigured? If an administrator sets the module parameter list_limit to a negative value (like -1 to mean unlimited), a large head.count from userspace can bypass the limit check in udmabuf_ioctl_create_list() because head.count is an unsigned u32 and list_limit is promoted to unsigned for the comparison. If a user calls ioctl(UDMABUF_CREATE_LIST) with a crafted head.count of 0x20000001, the allocation size calculation in udmabuf_ioctl_create_list() overflows: drivers/dma-buf/udmabuf.c:udmabuf_ioctl_create_list() { ... lsize = sizeof(struct udmabuf_create_item) * head.count; list = memdup_user((void __user *)(arg + sizeof(head)), lsize); } The size calculation evaluates to 0x300000018, which is truncated to 24 bytes when assigned to the u32 lsize variable. memdup_user() then allocates a 24-byte buffer for the list. When execution reaches udmabuf_create(), the loop iterates head->count times: drivers/dma-buf/udmabuf.c:udmabuf_create() { ... for (i = 0; i < head->count; i++) { pgoff_t subpgcnt; if (!PAGE_ALIGNED(list[i].offset)) goto err_noinit; ... } Since the list buffer is only 24 bytes long but the loop iterates 0x20000001 times, does this result in out-of-bounds reads on the kernel heap that could trigger a page fault and kernel oops? > ubuf = kzalloc(sizeof(*ubuf), GFP_KERNEL); > if (!ubuf) > return -ENOMEM; [ ... ] -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
