- 01 Mar, 2021 1 commit
-
-
Michael Cook authored
-
- 28 Feb, 2021 3 commits
-
-
Michael Cook authored
This code allocates memory from the heap: ``` static void *UE_phy_stub_standalone_pnf_task(void *arg) { ... UL_INFO->crc_ind.crc_indication_body.crc_pdu_list = calloc(NB_UE_INST, sizeof(nfapi_crc_indication_pdu_t)); ``` I see NB_UE_INST==1. Then this code: ``` void fill_crc_indication_UE_MAC(int Mod_id, int frame, int subframe, UL_IND_t *UL_INFO, uint8_t crc_flag, int index, uint16_t rnti, nfapi_ul_config_request_t *ul_config_req) { ... nfapi_crc_indication_pdu_t *pdu = &UL_INFO->crc_ind.crc_indication_body .crc_pdu_list[UL_INFO->crc_ind.crc_indication_body.number_of_crcs]; ``` used .number_of_crcs to index into .crc_pdu_list without first checking if .number_of_crcs is in range. When run with multiple UEs, sometimes .number_of_crcs==1 and then -fsanitize=address complains. Change is to use NUMBER_OF_UE_MAX instead of NB_UE_INST. With this change, -fsanitize=address stopping complaining.
-
Michael Cook authored
-fsanitize=address complained about this code.
-
Michael Cook authored
-fsanitize=address detected that we were trying to access bytes past the end of a block of malloc'ed memory. Specifically, in this code: ``` } else if (ENB_NAS_USE_TUN) { if( LOG_DEBUGFLAG(DEBUG_PDCP) ) log_dump(PDCP, pdcpData, sizeToWrite, LOG_DUMP_CHAR,"PDCP output to be sent to TUN interface: \n"); ret = write(nas_sock_fd[0], pdcpData, sizeToWrite); ``` -fsanitize=address said: ``` ==80==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61100004ffdc at pc 0x7f57c5f576a5 bp 0x7f57bb53c240 sp 0x7f57bb53b9e8 READ of size 108 at 0x61100004ffdc thread T7 0x61100004ffdc is located 0 bytes to the right of 220-byte region [0x61100004ff00,0x61100004ffdc) ``` So, the code was trying to access the first byte after a block of heap memory. sizeToWrite was calculated like this: ``` int sizeToWrite= sizeof (pdcp_data_ind_header_t) + pdcpHead->data_size; ``` There were a few other similar invocations of write() in the same function used the wrong size. That sizeToWrite calculation should be used only when the header is being sent, too, which happens in only one place in this function. With this commit, our tests pass and -fsanitize=address is happy.
-
- 27 Feb, 2021 4 commits
-
-
Michael Cook authored
Found by -fsanitize=address
-
Michael Cook authored
The global mbms_rab_id was defined as `uint16_t` in eNB_scheduler_mch.c but `int` in other places. So, code that wrotes this global would clobber the two bytes that follow the variable in memory. Found by `-fsanitize=address`.
-
Michael Cook authored
Found by `-fsanitize=address`.
-
Michael Cook authored
In phy_free_lte_eNB in lte_init.c, the lte-uesoftmodem would crash during shutdown because it was dereferencing null pointers. This commit adds checks to avoid that.
-
- 26 Feb, 2021 1 commit
-
-
Melissa Elkadi authored
For some reason the htons invocation got deleted which broke the VNF P7 interface. Also fixed some build issues, not sure how these got onto the develop branch to begin with.
-
- 24 Feb, 2021 4 commits
-
-
Melissa Elkadi authored
Removing references to memcpy_dl_config_req and memcpy_tx_req because these functions are leaking memory. For our standalone mode we have created new/modified memcpy_dl/tx_req functions.
-
Remi Hardy authored
MR1046 : Add support for NR UL SC-FDMA up to 100 MHz MR1053Nr : pdcp nea2 security MR1049 : improve rfsim -Fix a regression Earlier parameter reading was moved to an external thread, Eventually the check at the end of the main was too early, Declaration of some extra parameters are now on command line -Enhancement: use the rfsim as a server on UE side, so we can connect two xNB to one UE -Simplification: remove rfsim flags that have been made for convergence with replay function in usrp driver, but this is useless as they changed their code -Fix a bug in ubuntu 20.04 (now the code is ready in whole OAI) MR1056 : Bugfix: NR BSR calculation Fixes a bug in the scheduler for BSR calculation. Before, we might wrongly track the BSR of a UE and not schedule it anymore although it has data. Should be fixed now and improve UL throughput. MR963 : Nr mac multi rach global edge -Handling of Multiple Users triggering RACH request in different RACH Occasions in same slot -Providing Random Access Response according to RACH request
-
Melissa Elkadi authored
-
Melissa Elkadi authored
-
- 23 Feb, 2021 6 commits
-
-
hardy authored
-
hardy authored
-
hardy authored
-
hardy authored
-
hardy authored
-
Remi Hardy authored
MR978 : We have incorporated 5G NR nFAPI into the develop branch P5 and P7 interfaces for NR have been implemented. With this MR, downlink transmission through nFAPI will be possible. We have also made sure that 4G nFAPI can be used from within the develop branch.
-
- 21 Feb, 2021 1 commit
-
-
Gokul Srinivasan authored
-
- 19 Feb, 2021 2 commits
- 18 Feb, 2021 5 commits
-
-
Laurent Thomas authored
-
Laurent Thomas authored
-
Mahesh authored
-
Francesco Mani authored
-
Melissa Elkadi authored
Also, updated openairinterface5g_limits.h to match develop branch.
-
- 17 Feb, 2021 1 commit
-
-
Robert Schmidt authored
1) Only count new transmission as scheduled bytes (which is then compared against the BSR) 2) When subtracting scheduled bytes after successful reception, subtract TBsize from correct HARQ process
-
- 15 Feb, 2021 11 commits
-
-
Melissa Elkadi authored
-
Melissa Elkadi authored
-
Melissa Elkadi authored
Mutexes were not being initialized. In multiple places they were not being unlocked. In fill rach it was not being locked or unlocked.
-
Melissa Elkadi authored
-
Cedric Roux authored
go figure...
-
Cedric Roux authored
Dirty!
-
Cedric Roux authored
Dirty.
-
Cedric Roux authored
Dirty...
-
Cedric Roux authored
- a new section in the configuration file to select security algorithms, with new code to deal with it - cleanup CG-ConfigInfo: specs seem to indicate that we must not add mcg_RB_Config; the gNB has to deal with that - as a consequence, modify fill_default_rbconfig() that is called in every cases and needs security and bearer parameters The new section in the configuration file looks like: security = { # preferred ciphering algorithms # the first one of the list that an UE supports in chosen # valid values: nea0, nea1, nea2, nea3 ciphering_algorithms = ( "nea0", "nea2" ); # preferred integrity algorithms # the first one of the list that an UE supports in chosen # valid values: nia0, nia1, nia2, nia3 integrity_algorithms = ( "nia0" ); };
-
Cedric Roux authored
-
Cedric Roux authored
The code is forced to use nea2, no matter what the UE supports. After 2^18 PDCP packets, it will fail to work (we don't use HFN yet). These limitations will be fixed in later commits. The existing security function was not reused, because it does too much memory allocation and initializes the security context at each ciphering. So here comes nr_pdcp_security_nea2_cipher(). And also the ciphering is done inplace. To be changed if necessary.
-
- 13 Feb, 2021 1 commit
-
-
Raymond Knopp authored
Conflicts: common/utils/LOG/log.h common/utils/ocp_itti/intertask_interface.cpp nfapi/oai_integration/nfapi_vnf.c nfapi/open-nFAPI/nfapi/src/nfapi.c openair2/LAYER2/MAC/main_ue.c openair2/LAYER2/PDCP_v10.1.0/pdcp.c openair2/LAYER2/PDCP_v10.1.0/pdcp_fifo.c openair2/PHY_INTERFACE/phy_stub_UE.c openair2/RRC/LTE/rrc_UE.c openair2/RRC/LTE/rrc_eNB.c openair3/NAS/UE/ESM/esm_ebr_context.c targets/COMMON/openairinterface5g_limits.h targets/RT/USER/lte-softmodem.c targets/RT/USER/lte-uesoftmodem.c
-