Claude review: misc: fastrpc: fix DMA address corruption due to find_vma misuse

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Correctness: Good.** The core issue is well-identified. At line 1044 (post-patch):

```c
vma = vma_lookup(current->mm, ctx->args[i].ptr);
if (vma)
    pages[i].addr += (ctx->args[i].ptr & PAGE_MASK) -
                     vma->vm_start;
```

With the old `find_vma()`, if `ctx->args[i].ptr` fell in a hole before the returned VMA, `(ctx->args[i].ptr & PAGE_MASK) - vma->vm_start` would produce a large unsigned underflow, corrupting `pages[i].addr`. With `vma_lookup()`, such cases correctly return NULL and the offset is not applied.

**One observation:** When `vma_lookup()` returns NULL (address not in any VMA), the code silently proceeds with `pages[i].addr` set to the raw `ctx->maps[i]->dma_addr` without any offset, and continues to compute `pages[i].size` based on the pointer. This means a bad user-supplied pointer won't cause an immediate error — it will send a potentially wrong DMA address to the DSP. The existing code had this same "silent fallthrough" behavior with `find_vma()` (just the `if (vma)` guard was already there), so this patch doesn't make it worse, but a follow-up that returns an error when `vma_lookup()` returns NULL would be a stronger fix. That said, it's out of scope for this minimal fix and the Fixes/Cc:stable tags are appropriate.

**Commit message: Good.** Clear explanation of the root cause (underflow in the offset calculation), the trigger (address in a gap before the VMA), and the fix (switch to `vma_lookup()`). The Fixes tag correctly references commit `80f3afd72bd4` which introduced the `find_vma()` usage.

**Tags: Correct.** Cc: stable, Fixes, Reported-by, and Signed-off-by are all present and properly formatted.

**No other issues found.** The patch is a clean one-line change with no side effects.

---
Generated by Claude Code Patch Reviewer