[Pcsclite-muscle] Possible data truncation on receive in 1.8.14
Sat Nov 14 13:34:50 PST 2015
2015-11-13 21:23 GMT+01:00 Marcin Cieslak <saper at saper.info>:
> On Fri, 13 Nov 2015, Ludovic Rousseau wrote:
> > 2015-11-13 15:35 GMT+01:00 Marcin Cieslak <saper at saper.info>:
> > > This happens when passing data to CT API:
> > >
> > > char CT_data(unsigned short ctn, /* Terminal Number */
> > > unsigned char *dad, /* Destination */
> > > unsigned char *sad, /* Source */
> > > unsigned short lc, /* Length of command */
> > > unsigned char *cmd, /* Command/Data Buffer
> > > unsigned short *lr, /* Length of Response
> > > unsigned char *rsp /* Response */
> > >
> > > The supplied buffer length on my system, 65548 (hex 0x1000c) gets
> > > downcast to (unsigned short), which is 12.
> > >
> > > CT-API will not accept a buffer longer than 64KB. (No wonder given its
> > > origins).
> > >
> > Maybe you can fix CT-API API to use "unsigned int" for a buffer size
> > instead of "unsigned short".
> No, one can't. The CT-API specification says the length of response
> is "IU16" - integer, unsigned, 16bit.
> as far as I know most card readers produced or designed in Germany
> use CT-API internally even if they expose PC/SC interface.
Well, maybe not fix CT-API but at least fix the driver you are using.
I guess you do not use CT-API if you use PC/SC.
CT-API is just an internal API.
I seriously doubt such the readers accept larger buffer sizes.
> 8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7 is strange because
> requested buffer size given by the client application is no
> longer used(!), only maximal value is used.
The size given by the client is used to report an error if the buffer is
The test is performed _after_ the command has been sent to the cardreader +
I do not plan to change pcsc-lite just because CT-API is limited.
Dr. Ludovic Rousseau
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pcsclite-muscle