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.
-Mukesh
>
>
--
-Mukesh Ojha
