hub: status-change bitmap is read as one byte, ports 8 and up are never seen
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- c
- Domain
- embedded-iot
Research direction
Start with src/host/hub.c, especially hub_edpt_status_xfer() and hub_xfer_cb(), and read the existing hub host tests in test/unit-test/test/host/hub/test_hub_host.c. Add a 9-port hub test that reports a change on port 8, then run the hub host unit tests. Done means the request and bitmap decoding cover the required bytes and the test detects the port-8 change; hardware checking is optional if a suitable hub is available.
Written by the indexing model from the issue text.
Description
Found while reviewing #3776. Line numbers are at master 3174e7603.
The hub status-change bitmap is handled as a single byte:
hub_edpt_status_xfer()requests 1 byte (src/host/hub.c:254), althoughstatus_changeis 4 bytes (:37).hub_xfer_cb()reads the bitmap asuint8_t(:371) and tests ports 1..bNbrPortsagainst it (:383-384).
In the bitmap, bit 0 is the hub and bit N is port N (USB 2.0 §11.12.4), so on a hub with 8 or more ports, ports 8..N are reported in the second byte.
Effect:
- A change on port 8 or higher is never decoded.
- A hub sending a 2-byte bitmap into a 1-byte request may make the HCD report an overflow. With #3776 that counts as a failed poll, so the hub drops to the EP0 status fallback. This is unverified on hardware.
Remaining work:
- Request
(bNbrPorts + 8) / 8bytes, within the buffer size, and decode the bitmap over multiple bytes. - Add a unit test in
test/unit-test/test/host/hub/test_hub_host.cwith a 9-port hub that reports a change on port 8. - Check it on a hub with 8 or more ports, if one is available.
Deferred because it is pre-existing and separate from #3776's recovery path.
- Dominant language
- C
- Stars
- 7.2k
- Forks
- 1.6k
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 96
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hathach/tinyusb
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
test_audio_host: out-of-bounds read in test_audio_host_uses_exponential_full_speed_iso_intervalOpenfollowup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
FriendsofECCE/ECCE#519 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 95/100
containers/crun#2415 ·
Maintainers usually reply within 1 day
-
Bluetooth: Controller: memcpy() with NULL source in HCI extended and periodic reportsPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zephyrproject-rtos/zephyr#123423 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day