Comment # 1
on bug 12278
from Guy Harris
(In reply to Buildbot Builder from comment #0)
> =================================================================
> ==6454==ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0x7ffc50966c90 at pc 0x7f754c35ad85 bp 0x7ffc50966b90 sp 0x7ffc50966b88
> READ of size 1 at 0x7ffc50966c90 thread T0
> #0 0x7f754c35ad84
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/
> lib/libwireshark.so.0+0x796ad84)
> #1 0x7f754bd75891
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/
> lib/libwireshark.so.0+0x7385891)
(long list of random addresses with no symbolic interpretation whatsoever)
...
> Address 0x7ffc50966c90 is located in stack of thread T0 at offset 80 in frame
> #0 0x7f754c359b6f
> (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install/
> lib/libwireshark.so.0+0x7969b6f)
>
> This frame has 3 object(s):
> [32, 80) 'new_slots.i' <== Memory access at offset 80 overflows this
> variable
> [112, 208) 'other_slots.i'
> [240, 248) 'item.i'
OK, so it can't look at the instruction addresses and say "this is in
dissect_schedule_message()", but it *can* determine the names of *local
variables* in the stack frame for that routine?
Whiskey Tango Foxtrot? What is *wrong* with ASAN here?
Anyway, that sure appears to be dissect_schedule_message() in
epan/dissectors/packet-gsm_cbch.c, as that's the only routine I could find in
Wireshark with those variable names.
Some of the references to new_slots[] in that routine look OK - they're using i
as the index, and i is guaranteed to be < k, and k is guaranteed to be < 48
unless I'm missing something.
However, in
else if (octet1 == 0x40)
{
/* MDT 010000000 */
proto_tree_add_uint_format_value(sched_subtree,
hf_gsm_cbch_slot, tvb, offset++, 1, new_slots[k],
"%d Free Message Slot, optional reading",
new_slots[k]);
other_slots[new_slots[i] - 1] = 0xFFFE;
}
else if (octet1 == 0x41)
{
/* MDT 010000001 */
proto_tree_add_uint_format_value(sched_subtree,
hf_gsm_cbch_slot, tvb, offset++, 1, new_slots[k],
"%d Free Message Slot, reading advised",
new_slots[k]);
other_slots[new_slots[i] - 1] = 0xFFFE;
}
else
{
/* reserved MDT */
proto_tree_add_uint_format_value(sched_subtree,
hf_gsm_cbch_slot, tvb, offset, 1, new_slots[k],
"%d reserved MDT: %x", new_slots[k],
octet1);
other_slots[new_slots[i] - 1] = 0xFFFE;
}
new_slots[k] doesn't look right, as k is one past the last element of new_slots
that we've set. Perhaps new_slots[i] was what was meant here?
You are receiving this mail because:
- You are watching all bug changes.
