CC3120MOD: API receive delivering more bytes than the parameter length allows, causing corruption

Hi,

It seems you not have uploaded any ServicePack inside device. Please upload ServicePack into device as is stated in this article. Also you can try with latest host drives - see this answer.

Jan

Hi Jan,

Thanks for the reply.

As the hardware is custom, there's some work involved in trying to upload a service pack. Before I commit effort to trying that, could you let me know if there is a specific fix that you know of in the service pack (for the sl_Recv overrunning the buffer), or if the suggestion to update is a generic one to get the latest and greatest version which might fix the issue?

Looking in the SDK release notes, i didn't notice a receive buffer overflow mentioned

http://software-dl.ti.com/simplelink/esd/simplelink_msp432_sdk/3.40.00.05/docs/simplelink_mcu_sdk/changelog_coresdk_msp432p4_4_40_00_03.html#core-sdk-4.30.01-sep-24-2019

The SimpleLink™ software development kit (SDK) Wi-Fi® plug-in doesn't seem to have a similar release notes page and within the service pack, the release_notes.html doesn't list previous versions.

Colin

Hi Colin,

I am not aware about such kind of fix in SDK or ServicePack. Personally I think that you have issue with porting of host driver to your platform, but SDK and SP update sounds me like a best elimination procedure.

Using CC3120 device without proper service pack is really bad idea. For example your device without any ServicePack is affected by KRACK vulnerability and have many unfixed bugs and potential interoperability issues.

Jan

Hi Jan,

Thanks again. Finding out about a vulnerability is a big silver lining to this cloud; as we're heading to production soon, we'll need to write that in to the process.

Which number (FW, NwP or Phy) points out that there isn't a service pack installed? (So I can get the microcontroller software to double check a minimum level)

Colin

Hi Colin,

Best indication is NWP version.

• You have version: 3.3.99.1
• Latest service for CC3x20 is: 3.14.0.0
• ServicePack version 3.3.0.0 was part of SDK 1.30 from Mar 2017 (that means your device version is approximately 3 years out of date)

Jan

Hi Colin,

The SimpleLink Wi-Fi devices ship with firmware in ROM, which is the version you see. The servicepacks are essentially firmware patches that are stored in the serial flash. They can be updated via flashing or OTA method.

I do agree with Jan that you should test with an updated servicepack, but it would also be good to know how you ported your host driver. What host driver version are you using? There should be a SL_DRIVER_VERSION define in simplelink.h. Could you share your user.h?

Best regards,

Sarah

Hi Sarah,

From simplelink.h

#define SL_DRIVER_VERSION   "2.0.1.19"

I've inserted user.h

We're going to try setting the service pack using the CC3120MOD's own simplelink interface and app. Failing that, resort to getting a CC31XXEMUBOOST and using UniFlash.

Thanks,

Colin

2626.user.h

Hi Colin,

Your driver version is extremely old (SDK 1.40 - Jun 2017). You need to update your driver definitely.

Please see this thread. There are discussed possibilities how to update ServicePack at CC31xxMOD device

Jan

Hi Colin,

Your user.h looks fine, but I'd like to confirm the parameters that you pass for your SPI read and sl_Recv.

May I ask why you started development on an old software package? I'd like to understand if we need to update our documentation or web links somewhere. You can find our latest Wi-Fi plugin here: http://www.ti.com/tool/SIMPLELINK-SDK-WIFI-PLUGIN

Best regards,

Sarah

Hi Sarah,

The code used is 

/*
 Receive data from the remote host.

 \param         pBuffer         The pointer in which to store the data received
 from the host.
 \param     len             Specifies the length in bytes of
 the buffer pointed to by the buffer argument.
 Range: 1-16000 bytes

 \return    the number of received bytes on success (>=0) or -1 on failure
 */
int16_t cc3120_socket::receive(char * pBuffer, int16_t len) {

    const int16_t ret = sl_Recv(currentSockID, pBuffer, len, 0);
    return ret;
}

which being used from receive_all

/*
 Receive all the data from the remote host.

 \param     pBuffer     Pointer in which to store the data received from
 the host.
 \param     length      The maximum length of the buffer.

 \return        the number of received bytes on success (>=0) or -1 on failure
 */
int16_t cc3120_socket::receive_all(char *pBuffer, int16_t len) {
    int16_t recv = 0;
    while (recv < len) {
        const int16_t ret = receive(pBuffer + recv, len - recv);
        if (ret < 0) {
            return -1;
        } else if (ret == 0) {
            return recv;
        } else {
            recv += ret;
        }
    }
    return recv;
}

Which is called from an mbed thread that had a static buffer char[512]      (magic number for this post, the real code uses constants!)

and essentially calls receive_all(buffer, sizeof(buffer))        

i verified with the debugger that the buffer and length were valid. Static analysis was happy too.

As for the age of the library; this product has been updated, changing the wifi module to get certification for the countries we want to sell in.

Another product already uses the CC3120MOD, so we lifted the electronics and code from there to this product. It turns out that the module was there as future proofing, just being held in reset at the moment, so the code had not really been exercised beyond a few simple proof of hardware tests (e.g. getting it to ping google). That product is about 2 years old, so that dates the library version being used. This product's assumption was that we were inheriting working product code and we wouldn't need to change anything.

The module is now being added to product lifetime support for vulnerabilities and we're looking in to how we can update service packs when needed for a ten year product life. Vulnerabilities/bugs happen of course, but I don't know if there is somewhere we can register to get notified of important updates. I'm pleased that they take product security seriously here with a rigourous risk analysis and pen testing, but anything that backs up the reviews would be useful.

Thanks,

Colin

Hi Jan,

We purchased a CC31XXEMUBOOST board and wired that to Tx Rx, Reset and ground on our custom hardware. The SOP is wired to 000 but it didn't seem to matter (I expected it to need to be 010)

It took a while to get the board recognised on Windows 10 (lots of downloads and trying update driver to get the devices recognised). I abandoned trying the same on OSX (MacBook Pro) due to better familiarity with Windows device drivers.

Using UniFlash 5.3, two boards programmed to FW 2.0.0.0, NwP 3.11.1.0 and Phy 2.2.0.6 (though I found the interface a bit odd, since I was expecting more of a simple JTAG flasher type of interface)

Running the microcontroller interface unchanged, the module continued to successfully connected to our server.

Reducing the workaround code that increased the read buffer size from 512 to 1500, carried on working.

Reducing the guard memory around read buffer worked too.

I'll test more extensively today and look at the microcontroller code for the CC3120 API; I would expect to have to update that side too.

Thank you for your help, it's looking promising,

Coiin

Hi Coiin,

OK, let me know if you will have any issue.

For uploading Servicepack/image is used UART via bootloder code because this informations are inside SPI flash memory. And programming SPI flash via JTAG will be little bit hard to do.

Jan

Hi Jan,

While reviewing the issue, I noticed that you stated the that the latest service pack is 3.14

The latest service pack I could find is simplelink_cc3x20_servicepack_3.11.1.0_2.0.0.0_2.2.0.6   i.e. 3.11

Is there another service pack? 

Thanks,

Colin

P.S. I find the ti.com site search unhelpful, e.g. search for 'simplelink service pack' and none of the links actually get to the service packs

Hi,

Latest ServicePack for CC3220/CC3120 device you find under CC32xx SDK. Latest SDK is 3.40 with ServicePack version 3.14. Latest host driver use find there as well. Here is a nice comment from Jesu how to update host driver.

Yes, I agree that sometimes is hard to find relevant informations at TI websites. Because I am not a TI employee, I am not able do with this issue anything.

Jan