Bug #3603
closed
ndn.lua: bad argument #2 to 'tvb'
100%
Description
Open the attached pcap file with:
wireshark -Xlua_script:/path/to/ndn.lua
and tell wireshark to decode the (only) packet using the NDN dissector (this is necessary because I was using non-standard ports).
The following error appears:
Lua Error: [string "/usr/local/share/ndn-dissect-wireshark/ndn.lu..."]:241: bad argument #2 to 'tvb' (number expected, got userdata)
Files
Updated by Junxiao Shi over 9 years ago
- Status changed from New to Code review
- Assignee set to Junxiao Shi
- % Done changed from 0 to 100
The parser is trying to read the Content field as TLV blocks; this is useful when payload indeed contains TLV blocks.
However, in this particular packet, the parser thinks one of the "TLV blocks" has a very large length, and then it attempts to read the next TLV block after such a large length, causing a buffer overflow.
https://gerrit.named-data.net/2976 patchset1 fixes the error by checking tvb length before reading any field.
The test case is this issue's attachment but with a port number changed to 6363 using HEX editor.
Updated by Junxiao Shi over 9 years ago
- Has duplicate Bug #3602: ndn.lua: Range is out of bounds added
Updated by Alex Afanasyev about 9 years ago
Agree with the fix, but somehow, I cannot reproduce the problem on OSX. I tried Wireshark 2.0.2rc1 and the latest stable 2.0.4.
Updated by Davide Pesavento about 9 years ago
Alex Afanasyev wrote:
I cannot reproduce the problem on OSX. I tried Wireshark 2.0.2rc1 and the latest stable 2.0.4.
What version of Lua? I think the original report was from Ubuntu 15.10 (hence Wireshark 1.12.x), but I can still reproduce on Ubuntu 16.04 with Wireshark 2.0.2 and Lua 5.2
Updated by Alex Afanasyev about 9 years ago
I have lua 5.2 with wireshark 2.0.4. Then there is something special on OS X.
Updated by Junxiao Shi about 9 years ago
- Status changed from Code review to Closed