USB MSC library - null pointers

Stefano Zanotti · ‎2016-07-10

Posted on July 11, 2016 at 08:28

In the file ''usbh_msc.c'' generated by CubeMX there seem to be various instances of null pointer dereferencing.

Many functions begin with this statement:

MSC_HandleTypeDef *MSC_Handle = (MSC_HandleTypeDef *) phost->pActiveClass->pData;

which doesn't check whether pActiveClass is NULL.

It seems that in some places the issue is quite harmless since there are other guards, like

if(phost->gState == HOST_CLASS)

in USBH_MSC_IsReady()

Nevertheless, in other places the problem is there, and it exists even when harmless (e.g. if you catch null pointer dereferencing by MPU-disabling access to the address 0x00000000.)

Is this a bug, or should the user code manually check for something, before calling functions like USBH_MSC_IsReady()?

What are those checks?

Amel NASRI · ‎2016-07-13

Posted on July 13, 2016 at 16:26

Hi stefano.qi,

Using CubeMX, the usbh_msc.c is not added if you don't select the correct class.

So I don't think that such issue may occur.

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Stefano Zanotti · ‎2016-07-14

Posted on July 14, 2016 at 10:11

The issue exists when everything is configured, too.

In ''usbh_core.c'', phost->pActiveClass is inited to NULL (USBH_Init() and USBH_DeInit()), and set to the proper value only during the device enumeration (USBH_Process(), case HOST_CHECK_CLASS).

Of course I can work around the problem by performing the check myself:

if(phost->pActiveClass && USBH_MSC_IsReady())

but it feels like USBH_MSC_IsReady() should do the check itself, instead of assuming everything is all right.