On 11/14/2015 10:34 PM, Ludovic Rousseau wrote: > 2015-11-13 21:23 GMT+01:00 Marcin Cieslak <[email protected] > <mailto:[email protected]>>: > > On Fri, 13 Nov 2015, Ludovic Rousseau wrote: > > > 2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[email protected] > <mailto:[email protected]>>: > > > > > 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. > > > 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 > too small. > The test is performed _after_ the command has been sent to the > cardreader + card. > > I do not plan to change pcsc-lite just because CT-API is limited.
I face the same problem with the openct API. I'll prepare a RFC patch that keeps the buffer overflow detection. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
