Wireshark-bugs: [Wireshark-bugs] [Bug 8735] USB CCID dissector "runs off the rails" when trying
Michael Mann
changed
bug 8735
| What |
Removed |
Added |
| CC |
|
mmann78@netscape.net
|
Comment # 5
on bug 8735
from Michael Mann
(In reply to comment #3)
> Weird, I'm sure that it worked, earlier. Since the USB CCID dissector
> doesn't hook into the main USB dissector's descriptor-handling stuff (and I
> suspect that dissector has its own bugs of this sort - I haven't looked at
> its code), I'd expect the "GET DESCRIPTOR Response CONFIGURATION" packets to
> be marked as malformed.
I also filtered on just "usbccid" and none of the displayed packets are
malformed. Only some of the USB URB packets (the 7 mentioned in comment #2)
are considered malformed. Should those be USB CCID packets and maybe that's
part of the problem?
> Then again, the initial patch was
> designed only to fix the bug with RDR_to_PC_DataBlock packets - but I'd be
> happy to roll another one.
Might as well fix them all since it appears a few may have that issue.
> The hf_ccid_dwLength thing seems weird - but I
> deliberately implemented it that way, originally, since the spec
> (http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf)
> says that the "dwLength" field is 4 bytes in size, and values are stored in
> little-endian format.
Then I think switching hf_ccid_dwLength to a FT_UINT32 would need to be
included (along with using tvb_get_letol instead of tvb_get_guint8)
> I was going to combine the new length tests with the
> existing sub_selected tests - but simply wrapping an (tvb_get_guint8(tvb, 1)
> != 0) around the code that dealt with handovers seemed less redundant/more
> obvious, at the time. I'm willing to try another approach, though
I thought just moving the length check before creating the new tvb would be
better for performance (and easier), but I also thought you could use the new
tvb to do the size check too.
You are receiving this mail because:
- You are watching all bug changes.
