laforge has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/42192?usp=email )
Change subject: ccid_device: Reject XfrBlock with zero-length data ......................................................................
ccid_device: Reject XfrBlock with zero-length data
While the CCID v1.1 spec seems to declare dwLength == 0 is within the valid range, it's of course a no-op as we cannot transact a TPDU that isn't there.
Change-Id: I65df88477e4b1c03dc20a8d41e5cbd1c9f363ba8 Closes: OS#6969 --- M ccid_common/ccid_device.c 1 file changed, 7 insertions(+), 0 deletions(-)
Approvals: Jenkins Builder: Verified laforge: Looks good to me, approved
diff --git a/ccid_common/ccid_device.c b/ccid_common/ccid_device.c index acee696..bf131a9 100644 --- a/ccid_common/ccid_device.c +++ b/ccid_common/ccid_device.c @@ -460,6 +460,13 @@ struct msgb *resp; int rc;
+ if (u->xfr_block.hdr.dwLength == 0) { + /* CCID Rev 1.1 permits a zero-length XfrBlock on the protocol level, but what should we do + * with a zero-length TPDU? We need to reject it as bError=1 (Bad dwLength) */ + resp = ccid_gen_data_block(cs, u->xfr_block.hdr.bSeq, CCID_CMD_STATUS_FAILED, 1, 0, 0); + goto out; + } + /* handle this asynchronously */ rc = cs->ci->slot_ops->xfr_block_async(cs, msg, &u->xfr_block); if (rc <= 0) {