hidpp: match answers only against a live reply buffer (#128, #90) - #129
Merged
Merged
Conversation
The raw-event path took a held send_mutex to mean a sync sender was waiting, and matched incoming HID++ reports against send_receive_buf, the previous sender's response on that sender's stack. Four senders here hold the mutex with no response buffer (the OLED frame worker and handback, the rev-light level sender, the G923 rev-light worker, which sleeps under it), so during their hold the stale pointer was followed; once the owning process had exited and its stack was unmapped, the read faulted in interrupt context and the kernel panicked with nothing in the journal. Photographed on a G923 Xbox in AC EVO (#128), the freeze #90 chased: RIP hidpp_match_answer+0x8, RSI a vmap-stack address, CR2 that address plus one (question->device_index). Clear the pointer under the mutex before releasing it, and gate the match on a live pointer as well as the mutex.
3 tasks done
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the kernel panic a G923 Xbox owner finally photographed in AC EVO (#128), the freeze #90 had been chasing for weeks.
What the photo shows:
RIP: hidpp_match_answer+0x8 [hid_logitech_dd], "Fatal exception in interrupt".RDXis the live report (direct-map address),RSIishidpp->send_receive_bufat a vmap-stack address, andCR2is that address plus one: the read ofquestion->device_indexon a stack that no longer exists.Why: the raw-event path takes a held
send_mutexto mean a synchronous sender is waiting, and matches every incoming HID++ report againstsend_receive_buf, which points at the previous sender's response on that sender's stack. Four senders in this driver hold the mutex with no response buffer of their own (OLED frame worker, OLED handback, rev-light level sender, and the G923 rev-light worker, which sleeps while holding it). A report arriving during their hold was compared against a dead frame; once the owning process had exited and its stack was unmapped, the read faulted in interrupt context and the kernel panicked, with nothing in the journal.Fix: clear the pointer under the mutex before releasing it, and run the matcher only with a live pointer.
Tests: the module builds clean on 7.2.6 (clang);
tests/effect-mathandtests/texture-mergepass. Not reproduced on hardware here (no G923 attached); the mechanism is read from the photo and the code.