For the reader of VENDOR_SCD, ->powered_off may be set in foreground.
This makes a race condition between intr_cb call back and libusb_free_transfer in do_close_reader,
which might cause segv.
Description
Description
Revisions and Commits
Revisions and Commits
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • gniibe | T5065 scdaemon doesn't detect card removal after boot/resume (Identiv SPR332v2) | ||
| Resolved | • gniibe | T5121 a race condition between intr_cb call back and libusb_free_transfer in do_close_reader |
Event Timeline
Comment Actions
For SPR532, we need following.
- We can't assume (like other card readers with interrupt transfer support) intr_cb is called when no-card is detected for SPR532.
- When card is removed during the communication, SPR532 never emit the interrupt transfer.
- Normally, card removal is detected by intr_cb.
- The card removal should be able to be detected by scd_update_reader_status_file, too
- No need of periodical call to scd_update_reader_status_file
- Only when a communication error, we call scd_update_reader_status_file to see the card status by apdu_get_status
- When no card is detected, close the reader from scd_update_reader_status
- No need of periodical call to scd_update_reader_status_file
And on close of the reader,
- it cancels the handle->transfer of intr_cb if ->power_off is not yet set (by intr_cb).
- ^-- no race here any more with the change
- before the change, it goes to libusb_free_transfer then intr_cb which accesses freed object.