# Incorrect Write Position in Block Device Trim Operation

In Monad's block device trim, a partial-page fragment is written back to the advanced offset instead of the original, corrupting the adjacent disk page.

- Payout: Contest reward
- Severity: medium
- Program: Monad
- Credited: inh3l
- Disclosed: 2026-02-26
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-09-monad#m-04
- Library page: https://bugbountylibrary.com/r/c4%3A2025-09-monad%3AM-04
- Tags: domain:oss impact:integrity kind:contest platform:code4rena sev:medium tech:linux technique:source-review vuln:memory-corruption

**Target:** async storage_pool.cpp chunk::try_trim_contents block device trim path
**Root cause:** range[0] is advanced by DISK_PAGE_SIZE to skip the partial page for the trim, but the same mutated range[0] is reused as the pwrite offset for restoring the preserved fragment, so the write lands one page too far.
**Steps:**
1. Trigger a trim where the boundary falls inside a disk page so remainder > 0.
2. Code reads the partial page from original range[0], then does `range[0] += DISK_PAGE_SIZE`.
3. Trim executes over the adjusted range.
4. Restore path calls `::pwrite(write_fd_, buffer, DISK_PAGE_SIZE, range[0])` using the advanced offset.
5. Observe the preserved fragment overwrites the next disk page instead of its original location.
**How found:** Code review of the trim path: noticed range[0] is mutated for the trim range but reused unchanged as the pwrite offset in the restore branch.
**Insight:** When a variable is mutated to adjust a range for one operation, check every later use of that same variable — restore/rollback paths that reuse the adjusted offset silently write to the wrong location.