Comment # 1
on bug 8169
from Evan Huus
(the code in question is currently at line 109 in the file)
My analysis:
The loop happens if (len + 12) overflows to 0, which happens when len is
exactly (UINT32_MAX - 11). However, to even get that far requires some other
stars to align.
On systems where sizeof(gint) is 32, tvb_new_subset will see the length as
negative and throw an exception, so it simply can't happen. On systems where
sizeof(gint) is 64, tvb_new_subset will see the correct length. However, it
will still throw an exception unless the packet's reported length remaining is
at least that large.
If the packet's reported length is sufficiently large then tvb_new_subset will
pass, however the call to the mtp dissector may still throw an exception if
insufficient real data is available.
I think this means you can create this with a single small packet:
1. Take a regular NWMTP packet containing at least one full MTP3 payload.
2. Craft the 'reported length' of the packet to some value larger than
UINT32_MAX + the original size of the packet
3. Craft the NWMTP length field to (UINT32_MAX - 11).
4. Run on a 64-bit system.
Note that this requires a capture format which supports 64-bit reported lengths
for packets. None of the modern capture formats do this (including pcap-ng,
which still uses an unsigned 32-bit integer).
---
Given all of the caveats (especially the need for a 64-bit reported length) I
am unconvinced this is actually a realistic bug. Does my analysis match yours?
Thanks,
Evan
You are receiving this mail because:
- You are watching all bug changes.