[Pcsclite-muscle] Possible data truncation on receive in 1.8.14

[Marcin Cieslak]

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.

https://www.tuvit.de/cps/rde/xbcr/tuevit_de/CTAPI11EN.pdf

as far as I know most card readers produced or designed in Germany
use CT-API internally even if they expose PC/SC interface. 

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.

Marcin