Attention is currently required from: Hoernchen, jolly, lynxis lazus.

laforge has posted comments on this change by laforge. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42192?usp=email )

Change subject: ccid_device: Reject XfrBlock with zero-length data ......................................................................

Patch Set 1:

(1 comment)

Patchset:

PS1:

Further the CCID with len 0 or 1 is allowed, it further crashs then when checking for the minimum TP […]

I think @pmaier just recently ran into a situation where 4-byte TPDU Was actually happening in practice. But that might actually ahve been an APDU? Phipipp, please comment here.

ETSI TS 102 221 Section 7.2.2.0 (T=0 protocol) clearly states:

All commands using the protocol T = 0 are initiated from the terminal by sending a five byte header, which informs the UICC what to do. The terminal will always act as master and the UICC as a slave. The direction of the transmission is assumed to be known to both the UICC and the terminal

Baed on that I would assume anything < 5 is invalid and indeed should be rejected with a dwLength error (1).

We might also simply test with third-party CCID readers like a cm6121 to see what they end up doing when receiving T=0 TPDU with 0-length or with less than 5 bytes. Chances are that pcscd's ccid driver (or other ccid drivers) then properly react to whatever those do?