Re: another error when gnokii --getsms

[Daniele Forsi]

I'm going to explain the gory details of this error. I have a
diagnosis but not a cure.

The following PDUs are those reported by Vieri (I modified the phone numbers)

this doesn't cause an error:
079121436587092106E109811111111111907012907241809070120150038000CBEEF3
these cause an error:
079121436587092106F109812222222222907032906171809070329061918000E72036BB
079121436587092106CD098133333333339080709002818090807002336080009FD6E494
079121436587092106DE09814444444444908021806421809080218064818000DDF4B2

if someone wants to experiment, he can copy one of those strings in fake.c

The error is an attempt to read data after the end of the PDU buffer
in common/gsm-sms.c around line 939:

if (parameter_indicator & 0x04) {
        /* TP-UDL  TP-User-Data-Length */
        /* TP-UD   TP-User-Data */
        COPY_USER_DATA(pdu, offset);
}

there is another potential out of bounds error in a loop e couple of
lines above, both can be caused by parameter_indicator (it is 0xCB,
0xE7, 0x9F and 0xDD respectively and because 0xCB & 0x04 == 0 the
first PDU doesn't cause the error), which is strange because only 3
bits+1 are defined, according to ETSI TS 123 040 V8.5.0 (2009-06), so
I would expect it to be in the range 0-7.

Maybe someone can explain where I go wrong while decoding the second PDU above:
0791214365870921 SMSC number
06 == 2 SMS-STATUS-REPORT | 4 TP-More-Messages-to-Send
F1 TP-Message-Reference
09812222222222 TP-Recipient-Address
90703290617180 TP-Service-Centre-Time-Stamp
90703290619180 TP-Discharge-Time
00 TP-Status
E7 TP-Parameter-Indicator
2036BB

phone numbers and dates have reasonable values so they are probably
decoded in the right way
TP-Parameter-Indicator & 0x80 causes 0x20 to be skipped and
COPY_USER_DATA() is passed the offset of 0x36 which is interpreted as
TP-User-Data-Length (the number of bytes to read), but there aren't so
many

In the third PDU TP-Parameter-Indicator is 9F which cause to skip
D6E494 and read out of bounds during "while (pdu[offset++] & 0x80);"
but even fixing that, COPY_USER_DATA() is passed an out of bounds
offset
-- 
Daniele Forsi