Wireshark-bugs: [Wireshark-bugs] [Bug 8697] Buildbot crash output: fuzz-2013-05-18-22876.pcap
Comment # 4
on bug 8697
from Anders Broman
(In reply to comment #3)
> This ASN.1 thing has always been a mystery to me.
>
> My guess is that
>
> #.FN_BODY CommonTransportChannelID VAL_PTR = &commontransportchannelid
> %(DEFAULT_BODY)s
> nbap_dch_chnl_info[commontransportchannelid].next_dch = 0;
>
> creates the function dissect_nbap_CommonPhysicalChannelID()
>
> the FN_BODY is executed before that would be used to dissect the variable by
> default (dissect_per_constrained_integer() in this case).
>
> When ommonTransportChannelID VAL_PTR = &commontransportchannelid is executed
> with commontransportchannelid==0, it's crashing.
>
> I have no idea how to fix this. Should
> commonTransportChannelID VAL_PTR = &commontransportchannelid
>
> moved behind the default_body when commontransportchannelid contains a
> correct value?
>
> It seems that the same mechanism is used in a number of other places...
Hi,
I don't follow the reasoning
> with commontransportchannelid==0, it's crashing.
Why and where would that cause a crash?
The statement above produces this C code
tatic int
dissect_nbap_CommonPhysicalChannelID(tvbuff_t *tvb _U_, int offset _U_,
asn1_ctx_t *actx _U_, proto_tree *tree _U_, int hf_index _U_) {
#line 689 "../../asn1/nbap/nbap.cnf"
offset = dissect_per_constrained_integer(tvb, offset, actx, tree, hf_index,
0U, 255U,
&commonphysicalchannelid, FALSE);
nbap_dch_chnl_info[commonphysicalchannelid].next_dch = 0;
return offset;
There should be a check that the returned
commonphysicalchannelid is less than maxNrOfDCHs I think.
The reason for setting it I think is because of difficultis in only filling the
struct with relevant data in the right placees as the ASN.1 structures are
reused in multiple places.
You are receiving this mail because:
- You are watching all bug changes.