Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 9247] Crash in TCP reassemble when a read filter is applied yielding no result

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 3 on bug 9247 from Jakub Zawadzki

(In reply to comment #2)
> Can you at least post output of gdb bt full (best tshark compiled with -O0).
> 
> Does tshark crash when you run:
> 
>  /tmp/wsroot/bin/tshark -r base.pcap 
> or
>  /tmp/wsroot/bin/tshark -r base.pcap -2
> or
>  /tmp/wsroot/bin/tshark -r base.pcap -Y smtp
> or 
>  /tmp/wsroot/bin/tshark -r base.pcap -2 -Y smtp
> ?
> 
> 
> and are you sure about bisection?
> 
> i.e. is b68e6dcc429d9dc8e0996c98c1e7ab3e38d75144 (r50590) last working commit
> and d296ebc5254f78f5c18cd066fc886002b900a0a8 (r50591) first not working one?


Ok it actually makes sense if we have exception throwed during
tvb_clone_offset_len()

old reassembly code was doing:
  fd->data = "" char *)g_malloc(fd->len);
  tvb_memcpy(tvb, fd->data, offset, fd->len);

so even if tvb_memcpy() throwed exception fd->data was not NULL (fd->data had
crap inside, but it didn't crash).

Now if tvb_memcpy() throws exception it can be NULL.

Could you add to reassemble.c:
    fd->tvb_data = (void *) 0xdeadbeaf;
before:
1021         fd->tvb_data = tvb_clone_offset_len(tvb, offset, fd->len);

run tshark again and check if it crashes with tvb address 0xdeadbeaf ?

---

      You are receiving this mail because:

• You are watching all bug changes.