aboutsummaryrefslogtreecommitdiffstats
path: root/src/libvlr
AgeCommit message (Collapse)AuthorFilesLines
2018-03-13vlr_ciph_result: fix use after free of imeisvNeels Hofmeyr2-2/+2
Define the struct vlr_ciph_result member .imeisv not as a char* but a char[] of appropriate length, to avoid the need to point to external memory. Thus fix a use-after-free in msc_cipher_mode_compl(), which defined the imeisv[] buffer in a sub-scope within that function, so that the .imeisv pointer was already invalid when fed to vlr_subscr_rx_ciph_res(). Did you notice that the commit summary rhymes? Closes: OS#3053 Change-Id: I90cfb952a7dec6d104200872164ebadb25d0260d
2018-03-10cosmetic: vlr_auth_fsm: log RAN and size along with SRES/RESNeels Hofmeyr1-2/+4
Change-Id: Ib0f9f573ffac2302fbd3ee28f48ccd8fce5fe286
2018-03-10cosmetic: vlr_auth_fsm: clarify decision on UMTS AKA or GSM AKANeels Hofmeyr1-19/+42
The code deciding on whether UMTS AKA is used was cascaded and convoluted. By flattening the decisions, they become easier to read and possibly catch more weird corner cases / log information more clearly. - First decide what AKA the RES length reflects. - Then decide whether all prerequisites for UMTS AKA are satisfied. - Finally, on UTRAN, turn down the auth if we don't have UMTS AKA, and neatly log all of the potential causes. One corner case that should never occur is that the UMTS AKA RES length is actually the same length as the GSM AKA SRES. If this nevertheless occurs, log this as an error, though not turning down authentication because of it. (The effect is that we would favor UMTS AKA when it has a res_len == sizeof(sres) and would not succeed to GSM AKA. At least the log will tell us why, now.) Adjust an expected test output, trivial logging difference. Change-Id: I43f7f301ea85e518bac91f707391a53182e54fab
2018-03-10vlr: fix GSM AKA in a UMTS AKA capable environmentNeels Hofmeyr2-2/+30
Switch by vsub->sec_ctx to use the proper Kc for ciphering. Even on an R99 capable MS with a UMTS AKA capable USIM, the MS may still choose to only perform GSM AKA, as long as the bearer is GERAN. The VLR already stores whether the MS replied with a GSM AKA SRES or a UMTS AKA RES in vsub->sec_ctx. So far, though, we were always using the UMTS AKA Kc just because the USIM and core net are capable of it, ignoring the choice the MS might have made in the Authentication Response. In msc_vlr_test_gsm_ciph, fix the test expectations to the correct GSM AKA Kc keys, showing that all of LU, CM Service Request and Paging Response now support MS choosing GSM AKA in a UMTS capable environment. Related: OS#2793 Change-Id: I42ce51ae979f42d173a45ae69273071c426bf97c
2018-03-02vlr_lu_fsm: guard against using the wrong fiNeels Hofmeyr1-34/+68
Various functions in vlr_lu_fsm.c belong to one of the four FSMs defined in that file. After the recent error was uncovered where the lu_fsm called lu_compl_fsm()'s termination function, I want to make sure it's correct. Introduce distinct inline functions to dereference the respective fi->priv pointers, each asserting that the fi indeed belongs to the proper FSM. Use those *everywhere* to dereference fi->priv. From this patch on, we are sure beyond doubt that we are not inadvertently passing an fi pointer to the wrong FSM's handling functions, though we will only catch this at runtime -- but then will immediately know the reason. vlr_lu_fsm.c is the only file defining more than one FSM, so the other FSM definitions are already reasonably safe. Change-Id: I7419a780ff2d8b02efc4195bb1702818e4df181c
2018-03-02vlr: fix post-auth LU failure handlingNeels Hofmeyr1-2/+2
From the vlr_loc_update() FSM, don't call the vlr_lu_compl_fsm_failure() function. These are two distinct FSMs with distinct priv pointers, but they are defined in the same .c file. In vlr_loc_upd_post_auth(), change two erratic calls of vlr_lu_compl_fsm_failure() to lu_fsm_failure(), so that the proper fi and priv struct are used. Fixes: OS#2947 Change-Id: I7fd2c6fa23254fffd0d526e53541f4068153929f
2018-02-28implement support for 3-digit MNC with leading zerosNeels Hofmeyr1-9/+1
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout the code base to be able to handle an MNC < 100 that has three digits (leading zeros). Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore), Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore) Change-Id: I82f0016d9512ee8722a3489a3cb4b6c704a271fc
2018-02-08GSUP: check osmo_gsup_encode() resultMax4-16/+32
Check and handle gracefully any error which might appear in osmo_gsup_encode() - mark corresponding functions with warn_unused_result attribute to make sure this failure is always checked against. Change-Id: I4551212011fb0bd898c020a183756ed7a9afb9e5 Related: OS#2864
2018-02-06Fix whitespace issuesMax1-1/+1
We don't usually put space before in-place increment or decrement. Let's make code look similar to other Osmocom projects. Change-Id: I5962431ad16c97e412939dc1b8949f6361a5c26e
2018-02-05Wrap osmo_strlcpy() callsMax1-7/+7
Using following semantic patch: @@ expression A, B, C; @@ - osmo_strlcpy(A, B, sizeof(A)); + OSMO_STRLCPY_ARRAY(A, B); Which was applied using following command: spatch --dir src -I src --sp-file strlcpy.spatch --in-place --recursive-includes All the calls to osmo_strlcpy() which use destination buffer obtained via sizeof() were replaced with the corresponding wrapper macro. Change-Id: I67b482dedfa11237ac21894fc5930039e12434ab Related: OS#2864
2018-01-28Shift ciphering algorithm selection from VLR to MSCHarald Welte3-32/+12
The VLR code seems to have the assumption that there is one particular algorithm to be used, as opposed to one of a set of algorithms. What's missing is basically to decide when/where to pick the best algorithm within the capabilities of the phone (classmark) and the network configuration (net->a5_encryption_mask). So far, libvlr has no notion of classmark. Rather, libmsc has. Why does the VLR care about the particular algorithm at all? The VLR should probably simply decide if it should use encryption or not, and if so, the MSC will figure which algorithm to use. Change-Id: I5ed80ca2086560a5975a758ec568a034a9a8ab89
2018-01-24VLR: constify GSUP-related function parametersMax1-5/+5
Change-Id: If3852e096210713cb5297f6b42ed66dbb98c4a50
2018-01-05Add control command to expire subscriberMax1-5/+16
It's equivalent of existing vty command: common part is extracted into shared helper function. Change-Id: I267886b7c79ed6d9c2f34a2e60d2972b7f4f4036
2017-12-31VLR: log subscriber updateMax2-11/+1
* move log helpers to generic header * log subscriber update It's handy for troubleshooting issues with subscriber update via GSUP from HLR. Change-Id: I1958aeeb3ea99831c7e2c5ee9a6b59834baf4520
2017-12-27Migrate from OpenSSL to osmo_get_rand_id()Max2-7/+5
This avoids potential licensing incompatibility and makes integration of Debian packaging patches easier. Related: OS#1694 Change-Id: I71cd631704a4dc155c6c752fee2a42cd6e2fa336
2017-12-18cosmetic prep: tell vlr_ops.set_ciph_mode() whether UMTS AKA is usedNeels Hofmeyr3-0/+10
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth tokens. tuple->vec.kc was calculated from the GSM algorithm and is not necessarily a match for the UMTS AKA tokens. To decide (in an upcoming patch) whether to use UMTS AKA derived Kc or the Kc from the auth vector, the set_ciph_mode() from vlr_ops needs to know whether UMTS AKA is being used. This could possibly derived from the msc_conn_ref, but all flags are already available in the vlr_lu_fsm and vlr_access_req_fsm. Hence add a umts_aka flag to the set_ciph_mode() callback invocation. The VLR FSMs thus decide whether UMTS AKA or GSM AKA is to be used during Ciphering Mode Command, which makes more sense than re-implementing the same decision process in the MSC. I considered placing the Kc derivation in vlr_set_ciph_mode() and only tell the MSC's set_ciph_mode() implementation the precise keys it should use, but the RAN particulars, and whether a Kc is used at all, rather belong with the MSC. Related: OS#2745 Prepares: If04e405426c55a81341747a9b450a69188525d5c Change-Id: I983c48347faf4ee1b405d8174b4e006c904157cf
2017-12-18cosmetic prep: publish vlr_use_umts_aka() decisionNeels Hofmeyr2-11/+18
During Set Ciphering Mode on GERAN, it is required to know whether UMTS AKA is used to decide which Kc to pick. Change static function is_umts_auth() into public vlr_use_umts_aka(), so future patches can re-use it. Prepares: If04e405426c55a81341747a9b450a69188525d5c Change-Id: I85d784c62ecbabdb6186a3dae4dcd554e7921041
2017-12-18vlr: debug log: log Ciphering Mode detailsNeels Hofmeyr1-0/+2
Change-Id: Ib19dfd7255bda01ebace62386df4ec89697d9d14
2017-12-05Add missing CFLAGSAlexander Huemer1-2/+10
Change-Id: I67b5d797a80b55e01dcdbb8c782748b049cf9199
2017-11-20vlr_subscr_conn_timeout(): don't fire events to discarded fiNeels Hofmeyr1-2/+6
Terminating one of the FSM instances may effect termination and deallocation of the others, as well as the vlr_subscr itself. So, reserve the vlr_subscr locally, and then dispatch events to exactly those FSM instances that exist. The changes in expected output in the msc_vlr_tests shows that the subscriber was deallocated from the first FSM termination, and now sticks around until we've checked both FSMs are gone. Change-Id: I56551ecc10f5295fe75944bdde4b583b1b621811
2017-11-20vlr_gsupc_read_cb: fix use after free of GSUP msgbNeels Hofmeyr1-5/+10
osmo_gsup_decode() doesn't actually decode everything, it does leave quite a number of pointers into the original msgb. Hence we must not deallocate the gsup msgb before dispatching GSUP events. Move msgb_free() to the bottom of vlr_gsupc_read_cb() and use rc and gotos to early-exit if needed. Change-Id: I16fc92dcf84e29fcf34712a2e8b0464ef08425ad
2017-11-20sub_pres_vlr_fsm_start: fix heap use after freeNeels Hofmeyr2-11/+16
When sub_pres_vlr_fsm_start() is called, it dispatches an event which may in some cases already cause tear down and free of the parent FSM instance, after which storing the returned instance pointer in that parent's metadata will use freed memory. Instead, pass the target pointer to remember the instance at to sub_pres_vlr_fsm_start() and assign the pointer *before* firing the event. Explain so in a new comment. I haven't checked whether that pointer is actually used at all -- this is the easiest way to fix the use-after-free without getting sucked into semantic questions. Change-Id: Ibdc0b64cd12ba3e2b9737e3517d8484e67abcf04
2017-11-12vlr: auth_fsm_start: check return value of fsm allocNeels Hofmeyr1-1/+4
Fixes: coverity CID#178663 Change-Id: I7d1c15b546377b1afa38f7f40c5421b743e21605
2017-10-31defaults: assign TMSI by defaultNeels Hofmeyr1-0/+3
When using ciphering, the TMSI is an important part of the ciphering. To guard against users forgetting to set 'assign tmsi' in the config and compromising their ciphering unknowingly, the default should be to use a TMSI. To optimize in an unencrypted network, 'no assign tmsi' config can still switch off TMSI use. Change-Id: If115e95bebc314bedb50faf3993b52071fee5c1e
2017-10-31cosmetic: vlr: rename auth_tuple_max_use_count to _reuse_Neels Hofmeyr1-16/+16
The name auth_tuple_max_use_count suggests that if I want to use each auth tuple exactly once, I need to set it to 1. Curiously, so far you need to set to intended uses - 1. Reflect this in its name by renaming to auth_tuple_max_reuse_count. I first considered to not rename but change the if-conditions so that == 1 means each tuple is used once, and upon struct vlr allocation, set the default to 1. That would also logically entail that setting to 0 means to re-use vectors infinitely often, like now a value < 0 does. That means, when allocating a vlr struct zeroed out, we would by default have the most dangerous/unsafe configuration. It's no problem to set a default to 1 upon allocation, but by renaming the variable instead, we get safer alloc-zero behavior and don't need to change any conditionals in the code (even though the patch ends up considerably larger from all the renaming). Change-Id: I0b036cae1536d5d6fb2304f837ed1a6c3713be55
2017-10-04cosmetic: vlr: declare a struct in .h; drop unused headerNeels Hofmeyr2-1/+2
In vlr_core.h, "pre-declare" a struct used in function declaration. In vlr_lu_fsm.c, gsup.h is not used, drop the #include. Change-Id: I61d793c3001abbe6d381be1ae0bb350b07403e88
2017-10-03fix memory leak: vlr: vlr_gsupc_read_cb() must msgb_free()Neels Hofmeyr1-0/+1
Add required msgb_free() to vlr_gsupc_read_cb(). Adjust msc_vlr_tests.c gsup_rx() to *not* free the msgb again after vlr_gsupc_read_cb() did. Related: OS#2476 Change-Id: I347c53f57a7fa79921aed3f6e42599841acf27c0
2017-09-15Remove rest_octets.hMax3-0/+4
The MSC should not fiddle with low-level SI details like rest octets anyway. Unfortunately simply removing the header is impossible as it causes massive fallout due to missing includes. Fixed it as well. The only other parameter which required removal is cell_ro_sel_par which is not referenced anywhere in the code anyway. Change-Id: Ibff77330de056fad4288cd4c48d016aad8105354
2017-09-06rename include/openbsc to include/osmocom/mscNeels Hofmeyr5-11/+11
Change-Id: I1f96a1285bbd1b4607614856bca935d5c26e2da9
2017-08-29split off osmo-msc: remove files, apply build, renameNeels Hofmeyr1-2/+14
Change-Id: Icf025e5ea8d180613b3114282951c9afa67af9a7
2017-08-08Implement IuCS (large refactoring and addition)Neels Hofmeyr3-0/+28
osmo-nitb becomes osmo-msc add DIUCS debug log constant add iucs.[hc] add msc vty, remove nitb vty add libiudummy, to avoid linking Iu deps in tests Use new msc_tx_dtap() instead of gsm0808_submit_dtap() libmgcp: add mgcpgw client API bridge calls via mgcpgw Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to be split up. Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
2017-08-07vlr: LU FSM: enable Retrieve_IMEISV_If_RequiredNeels Hofmeyr2-41/+51
Change-Id: I121b95ad6d5ecb7603815eece2b43008de487a8a
2017-08-07vlr: place comments on if (0) casesNeels Hofmeyr2-1/+8
Change-Id: I56c1e61dedeac01a4e24452feee6616782783d8f
2017-07-23Use libvlr in libmsc (large refactoring)Harald Welte1-0/+1
Original libvlr code is by Harald Welte <laforge@gnumonks.org>, polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>. This is a long series of trial-and-error development collapsed in one patch. This may be split in smaller commits if reviewers prefer that. If we can keep it as one, we have saved ourselves the additional separation work. SMS: The SQL based lookup of SMS for attached subscribers no longer works since the SQL database no longer has the subscriber data. Replace with a round-robin on the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the subscriber is currently attached. If there are many SMS for not-attached subscribers in the SMS database, this will become inefficient: a DB hit returns a pending SMS, the RAM lookup will reveal that the subscriber is not attached, after which the DB is hit for the next SMS. It would become more efficient e.g. by having an MSISDN based hash list for the VLR subscribers and by marking non-attached SMS recipients in the SMS database so that they can be excluded with the SQL query already. There is a sanity limit to do at most 100 db hits per attempt to find a pending SMS. So if there are more than 100 stored SMS waiting for their recipients to actually attach to the MSC, it may take more than one SMS queue trigger to deliver SMS for subscribers that are actually attached. This is not very beautiful, but is merely intended to carry us over to a time when we have a proper separate SMSC entity. Introduce gsm_subscriber_connection ref-counting in libmsc. Remove/Disable VTY and CTRL commands to create subscribers, which is now a task of the OsmoHLR. Adjust the python tests accordingly. Remove VTY cmd subscriber-keep-in-ram. Use OSMO_GSUP_PORT = 4222 instead of 2222. See I4222e21686c823985be8ff1f16b1182be8ad6175. So far use the LAC from conn->bts, will be replaced by conn->lac in Id3705236350d5f69e447046b0a764bbabc3d493c. Related: OS#1592 OS#1974 Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
2017-07-21Add libvlr implementationHarald Welte9-0/+4042
Original libvlr code is by Harald Welte <laforge@gnumonks.org>, polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>. This is a long series of trial-and-error development collapsed in one patch. This may be split in smaller commits if reviewers prefer that. If we can keep it as one, we have saved ourselves the additional separation work. Related: OS#1592 Change-Id: Ie303c98f8c18e40c87c1b68474b35de332033622
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 10:19:36 +0000