94xhn opened a new pull request, #19420: URL: https://github.com/apache/nuttx/pull/19420
## Summary `romfs_seek()` clamps the computed `position` to the file size when it exceeds `rf->rf_size`, but never checks for a negative result. `lseek(fd, offset, SEEK_SET/SEEK_CUR/SEEK_END)` calls that produce a negative `position` (e.g. a negative `SEEK_SET` offset, or a `SEEK_CUR`/`SEEK_END` offset more negative than the current position/file size) write that negative value straight into `filep->f_pos`. The subsequent `romfs_read()` computes `rf->rf_startoffset + filep->f_pos` into a `uint32_t` (`fs/romfs/fs_romfs.c`), so a negative `f_pos` wraps around to a huge unsigned offset, and `romfs_hwread()`'s XIP path `memcpy()`s from `rm_xipbase` plus that offset — an out-of-bounds read far past the mapped flash region. ## Fix Add the same `if (position < 0) return -EINVAL` guard already used by `fs/fat/fs_fat32.c`'s seek function, before the existing end-of-file clamp. ## Testing Wrote a standalone host-side C reproduction transcribing `romfs_seek()`, the downstream `romfs_read()` address computation, and `romfs_hwread()`'s XIP `memcpy()` verbatim from the current source, with a `SIGSEGV` handler around a deliberately small (1 MiB) `rm_xipbase` mapping: - **Before fix**: `lseek(fd, -600, SEEK_SET)` returns -1 but with the wrong errno (leaks the raw negative value instead of `EINVAL`), leaves `f_pos` corrupted at -600, and the downstream address computation wraps to `0xFFFFFDC8` (~4 GB out of bounds) — `romfs_hwread_XIP()` reading from that offset triggers a real `SIGSEGV` against the mapped buffer. - **After fix**: the same call correctly returns -1 with `errno == EINVAL`, and `f_pos` is left unchanged. - **Regression checks**: normal `SEEK_SET`/`SEEK_CUR`/`SEEK_END` seeks, EOF clamping (seeking past end-of-file), and the exact-zero boundary case (a `SEEK_CUR` that lands exactly at 0, which must *not* be rejected) all produce identical results before and after the fix. Assisted-by: Claude:claude-sonnet-5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
