Change in osmo-pcu[master]: rlcmac: Reproduce and fix stack smashing bug receiving RA cap

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Mon Mar 23 11:52:54 UTC 2020


Hello Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-pcu/+/17548

to look at the new patch set (#5).

Change subject: rlcmac: Reproduce and fix stack smashing bug receiving RA cap
......................................................................

rlcmac: Reproduce and fix stack smashing bug receiving RA cap

RA cap struct placed in unit test is taken from a real android phone
sending the value when attaching to the network. Then SGSN sends it back
and osmo-pcu would crash similar to unit test:
*** stack smashing detected ***: terminated
 Process terminating with default action of signal 6 (SIGABRT): dumping core
    at 0x4C62CE5: raise (in /usr/lib/libc-2.31.so)
    by 0x4C4C856: abort (in /usr/lib/libc-2.31.so)
    by 0x4CA62AF: __libc_message (in /usr/lib/libc-2.31.so)
    by 0x4D36069: __fortify_fail (in /usr/lib/libc-2.31.so)
    by 0x4D36033: __stack_chk_fail (in /usr/lib/libc-2.31.so)
    by 0x124706: testRAcap2(void*) (RLCMACTest.cpp:468)

So it seems the assumptions regarding maximum number of RA capabilitites
in one message were wrong. Doing some rough calculations, each RA
capabilitiy value (without extensions) can take around 20ish bits, which
means for a message containing up to 52 bytes that quite a lot of
different values could be theoretically fed in. Let's be safe and
increase the array size to be able to handle all different access
technologies listed in See TS 24.008 table 10.5.146 following
restrictions:
* "The MS Radio Access capability is a type 4 information element, with a maximum length of 52 octets."
* "Among the three Access Type Technologies GSM 900-P, GSM 900-E and GSM 900-R only one shall be present."
* "the mobile station should provide the relevant radio access
  capability for either GSM 1800 band OR GSM 1900 band, not both".

Wireshark requires similar fix (it's not important though because it
currently uses another ad-hoc decoder for RAcap).

Related: OS#4463
Change-Id: I5334eaacfbc238fae8bea50c9e9667c2117f81ff
---
M src/gsm_rlcmac.h
M tests/rlcmac/RLCMACTest.cpp
M tests/rlcmac/RLCMACTest.err
M tests/rlcmac/RLCMACTest.ok
4 files changed, 153 insertions(+), 15 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-pcu refs/changes/48/17548/5
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/17548
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: I5334eaacfbc238fae8bea50c9e9667c2117f81ff
Gerrit-Change-Number: 17548
Gerrit-PatchSet: 5
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: fixeria <axilirator at gmail.com>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200323/a2d88d42/attachment.htm>


More information about the gerrit-log mailing list