Dennis Lou writes: > The way I see it, Sam's buffer overflow concern is predicated on a > misbehaving device. I haven't witnessed it but it is possible given that > we're reverse engineering things rather than working from a formal spec. > Nicolas' buffer overflow concern is predicated on a misbehaving usb stack. > It's also possible, but probably less likely than Sam's concern. Which > to implement depends on how paranoid you are about the behavior of the > device and libusb.
Clarification: my patch is needed to fix the following bug, referenced earlier in the thread: >>> Hi Dennis, >>> >>> A bug was opened a while back by Sam Varshavchik, concerning the pixma >>> backend for Canon ImageClass MF-4270, when compiled and used on a 64 >>> bits platform (no issue so far on 32 bits), details are given here: >>> >>> https://alioth.debian.org/tracker/?group_id=30186&atid=410366&func=detail&aid=310861 The original code issues a read request to libusb for more bytes than actually expected, and, apparently, on some hardware that causes a USB timeout, with Various Bad Things?, as I described in the bug. Besides a single scan now taking ~30 minutes, the resulting pnm is corrupted. By changing the code not to ask to read more than what's expected, that fixes both the original bug, and the overflow problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20080625/f781e6d1/attachment.pgp
