Skip to content

hid: clamp report reads and survive a panicked command - #13

Merged
snekxs merged 1 commit into
mainfrom
fix/pr12-rebase
Oct 3, 2026
Merged

snekxs merged 1 commit into
mainfrom
fix/pr12-rebase

Conversation

@snekxs

@snekxs snekxs commented Oct 3, 2026

Copy link
Copy Markdown
Member

Supersedes #12 with the same commit rebased onto current main (no content change vs author's tip; fmt/clippy/test verified locally: 37+4 pass, fmt+clippy clean). Maintainer cannot push to the author's fork, so this branch carries the rebase instead.

hidapi on Windows adds one to a report read's byte count when the first
byte is 0, so a full 91-byte Razer feature read comes back as 92.
receive_feature_report sliced data[1..size] unclamped and panicked.
receive_input_report already clamped; both now share report_payload.

The panic poisoned the session lock. Every later command, list included,
was then answered with id 0, which the app ignores, so each request timed
out after 10s and the device could never be used. Bridge is a windowed app,
so the panic message never reached the log either. Recover the lock, log
the panic, and answer with the request's own id.

Seen on a Razer Diamondback Chroma (1532:004c) on Windows 10.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@snekxs
snekxs merged commit 2759518 into main Oct 3, 2026
4 checks passed
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.

2 participants