Re: [PATCH 3/3] remoteproc: add SPDX-License-Identifier tag to rsc_table.h

[XIAO WU]

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)

Thanks,
XIAOWU