cancel
Showing results for 
Search instead for 
Did you mean: 

USB MSC library - null pointers

Stefano Zanotti
Associate II
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?
2 REPLIES 2
Amel NASRI
ST Employee
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
Associate II
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.