Comment # 2
on bug 8169
from Moshe Kaplan
(In reply to comment #1)
> (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've truly done a better job at analyzing this than I have. I'm not confident
that this is a bug, as the title (hopefully) implies. My hope is that someone
more qualified will be able to decide if it is.
Thanks for looking at it,
Moshe
You are receiving this mail because:
- You are watching all bug changes.