Skip to content

fix: copyBytes source index wrapping in decode_reader#61

Open
hobeone wants to merge 1 commit into
nwaples:mainfrom
hobeone:fix/01-copybytes-wrapping
Open

fix: copyBytes source index wrapping in decode_reader#61
hobeone wants to merge 1 commit into
nwaples:mainfrom
hobeone:fix/01-copybytes-wrapping

Conversation

@hobeone
Copy link
Copy Markdown

@hobeone hobeone commented May 16, 2026

Full disclosure, this was found with an LLM analysis. Seems to be a real issue though - I didn't see a policy on accepting LLM changes or not so creating a pull request.

^^^ human -- LLM vvv

copyBytes is the LZ sliding-window copy primitive used by all RAR decompression versions (v2.0, v2.9, v5.0, v7.0). When the source index reaches the end of the circular window buffer, it must wrap to 0 — this is standard LZ77 circular-buffer behavior, not corruption.

The fast-path bulk-copy branch (i > d.w) already handled this wrap correctly by splitting the copy into two segments. However, the byte-by-byte fallback loop (used when source and destination overlap, e.g. RLE-like patterns) was missing the wrap, causing a panic with index-out-of-range on crafted RAR3 archives.

copyBytes is the LZ sliding-window copy primitive used by all RAR
decompression versions (v2.0, v2.9, v5.0, v7.0). When the source
index reaches the end of the circular window buffer, it must wrap
to 0 — this is standard LZ77 circular-buffer behavior, not corruption.

The fast-path bulk-copy branch (i > d.w) already handled this wrap
correctly by splitting the copy into two segments. However, the
byte-by-byte fallback loop (used when source and destination overlap,
e.g. RLE-like patterns) was missing the wrap, causing a panic with
index-out-of-range on crafted RAR3 archives.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant