Re: Possible data truncation on receive in 1.8.14

Marc Kleine-Budde <[email protected]> Tue, 8 Dec 2015 11:10:11 +0100
Newsgroups	gmane.comp.lib.muscle
Message-ID	<[email protected]>
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   |

_______________________________________________
Pcsclite-muscle mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
signature.asc (application/pgp-signature, 455 B)