1. 18 Mar, 2021 1 commit
  2. 15 Mar, 2021 1 commit
  3. 14 Mar, 2021 5 commits
  4. 13 Mar, 2021 6 commits
  5. 12 Mar, 2021 2 commits
  6. 11 Mar, 2021 2 commits
  7. 10 Mar, 2021 1 commit
  8. 07 Mar, 2021 1 commit
  9. 06 Mar, 2021 2 commits
  10. 05 Mar, 2021 3 commits
  11. 04 Mar, 2021 1 commit
  12. 03 Mar, 2021 1 commit
  13. 02 Mar, 2021 2 commits
  14. 01 Mar, 2021 5 commits
  15. 28 Feb, 2021 3 commits
    • Michael Cook's avatar
      lte-ue.c: Allocate bigger arrays · 034d2cfe
      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.
      034d2cfe
    • Michael Cook's avatar
      eNB_scheduler_ulsch.c: Range checking on array access · 11270af8
      Michael Cook authored
      -fsanitize=address complained about this code.
      11270af8
    • Michael Cook's avatar
      pdcp_fifo_flush_sdus: Fix message size calculation · 706f0e44
      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.
      706f0e44
  16. 27 Feb, 2021 4 commits