Skip to main content
Stefano Zanotti
Associate
July 11, 2016
Question

USB MSC library - null pointers

  • July 11, 2016
  • 2 replies
  • 716 views
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?
    This topic has been closed for replies.

    2 replies

    Amel NASRI
    ST Technical Moderator
    July 13, 2016
    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 "Best Answer" on the reply which solved your issue or answered your question.
    Stefano Zanotti
    Associate
    July 14, 2016
    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.