On Mon, Jun 22, 2026 at 11:57:44PM +0530, Mukesh Ojha wrote:
> On Sun, Jun 21, 2026 at 08:57:44AM +0800, XIAO WU wrote:
> > i Mukesh,
> >
> > I came across a Sashiko AI code review [1] that flagged a pre-existing
> > integer signedness bug in `rsc_table_for_each_entry()` in
> > include/linux/rsc_table.h. The `offset` variable is declared as `int`,
> > allowing a large unsigned offset value (e.g., 0xFFFFFFF0) to become
> > negative, bypass the `avail < 0` truncation check due to size_t
> > promotion, and read from before the resource table buffer.
> >
> > I was able to reproduce this in QEMU with KASAN by crafting an ELF
> > firmware image with a malicious resource table offset.
> >
> > On Wed, Jun 11, 2026 at 11:35:50PM +0530, Mukesh Ojha wrote:
> > > remoteproc: fix coding style issues in remoteproc.h
> > ...
> >
> > The bug is in the `rsc_table_for_each_entry()` macro further down in
> > rsc_table.h:
> >
> > ```c
> > for (i = 0; i < table->num; i++) {
> > int offset = table->offset[i]; // signed — attacker-controlled
> > struct fw_rsc_hdr *hdr = (void *)table + offset;
> > int avail = table_sz - offset - sizeof(*hdr);
> > ...
> > if (avail < 0) { ... } // bypassed via size_t promotion
> > ```
> >
> > If `table->offset[i]` is 0xFFFFFFF0, `offset` becomes -16 (signed).
> > When `avail = table_sz - (-16) - sizeof(*hdr)` is computed, the
> > negative `offset` is promoted to a large unsigned size_t, making
> > `avail` overflow to a small positive value. The `avail < 0` check
> > passes, and `hdr` points 16 bytes *before* the table buffer.
> >
> > [Reproduction]
> >
> > I compiled a fake ELF firmware with phnum=1 and a resource table whose
> > first offset entry is 0xFFFFFFF0. Writing "boot" to the remoteproc
> > sysfs state file triggers the resource parsing path:
> >
> > state_store → rproc_boot → rproc_fw_boot → rproc_parse_fw
> > → rproc_handle_resources → rsc_table_for_each_entry
> >
> > [KASAN report — kernel 7.1.0-rc6+, CONFIG_KASAN=y]
> >
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in
> > rproc_handle_resources.constprop.0+0x49b/0x510
> > Read of size 4 at addr ffff888031283790 by task poc/9573
> >
> > The buggy address belongs to the object at ffff8880312837a0
> > which belongs to the cache kmalloc-32 of size 32
> > The buggy address is located 16 bytes to the left of
> > allocated 20-byte region [ffff8880312837a0, ffff8880312837b4)
> >
> > Call Trace:
> > <TASK>
> > dump_stack_lvl+0x116/0x1f0
> > print_report+0xcd/0x630
> > kasan_report+0xe0/0x110
> > rproc_handle_resources.constprop.0+0x49b/0x510
> > rproc_boot+0x.../...
> > state_store+0x.../...
> > dev_attr_store+0x.../...
> > sysfs_kf_write+0x.../...
> > kernfs_fop_write_iter+0x.../...
> > vfs_write+0x.../...
> > ksys_write+0x.../...
> > do_syscall_64+0xcd/0xf80
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > The crash reads 4 bytes (the hdr->type field) from 16 bytes before the
> > kmemdup'd resource table buffer. The value read is 0xCCCCCCCC
> > (uninitialized kmalloc poison), confirming the negative offset bypassed
> > all bounds checks.
> >
> > [1]
> > https://sashiko.dev/#/patchset/20260611180550.2442641-3-mukesh.ojha%40oss.qualcomm.com
> > (Sashiko AI code review — "Out-of-Bounds Access", Severity: Critical)
> >
>
> Let me check and get back on this.., this looks to be existing bug.
> Thanks for reporting this.
This should fix this existing issue
https://lore.kernel.org/lkml/[email protected]/
>
> -Mukesh
> >
> >
>
> --
> -Mukesh Ojha
--
-Mukesh Ojha
