CC3220SF: HTTPClient - secAttribs not initialized

Igor Sverma

Part Number: CC3220SF

Hello,

it seems that in function HTTPClient_connect is a bug.

In case that exSecParams is NULL and cli->secAttribs is NULL (during first connection to server), the structure secAttribs is not allocated (just set to NULL and the memory after this pointer is used as the content of the structure later on). So in best case there are 0 in the memory and nothing goes wrong. But what happened in our case - payload was NULL and payloadLen was 1. Which ended up in fatal error in NWP.

So I modified this code:

SlNetSockSecAttrib_t *secAttribs = NULL;

if (exSecParams != NULL)
{
    ...
}
else if (cli->secAttribs != NULL)
{
    ...
}

To this code

SlNetSockSecAttrib_t *secAttribs = NULL;

if (exSecParams != NULL)
{
    ...
}
else if (cli->secAttribs != NULL)
{
    ...
}
else
{
	secAttribs = (SlNetSockSecAttrib_t *)calloc(1, sizeof(SlNetSockSecAttrib_t));
}

I have two questions:

1) Can you confirm the fix is right?

2) Do I need to clean (free) the secAttribs later, or if its already done by some other functions?

Igor

over 3 years ago

0 Kobi Leibovitch over 3 years ago

TI__Guru 61516 points

Hi,

I'm not sure I understand the problem.

secAttribes - should be only relevant when connection is secured (i.e. "https://"), and if it secured, then you need to configure the exSecParams.

what do you mean by "payload was NULL and payloadLen was 1" - what payload (the attribBuff?) and payloadLen?

Br,

Kobi

0 Igor Sverma over 3 years ago in reply to Kobi Leibovitch

Prodigy 245 points

Sorry, payload is naming down in NWP writing code .... you are right, I mean attribBuff and attribBuffLen

So, in case https://, we need to specify secAttribs? Even you want to omit some security? (it will work when you pass 0 as key, cert and root)

Wouldnt be better to call some kind of ASSERT in case of https and missing secAttribs, then sending random unallocated data to NWP, which can cause hardfault and then powercycle?

Igor

+1 Kobi Leibovitch over 3 years ago in reply to Igor Sverma

TI__Guru 61516 points

Yes, it would have been nice to add assert in such place (i will open an issue regarding this, but it will probably get a low priority when compared to the real functional issues).

"payload was NULL and payloadLen was 1" - seems like another user mistake. you shouldn't initiate the secAttribs that way (if this was just due to secAttribs used with pointer == 0, then ignore this because it is just by product of the first issue).

Note that the SDK code (especially the application level) is not trying to protect from all possible user errors.

Br,

Kobi

Wi-Fi

Wi-Fi forum

CC3220SF: HTTPClient - secAttribs not initialized