This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF51 SDK pstorage bug: bad memory access

Hi,

I'm using nRF51 SDK v 5.1.0 with SoftDevice v6.0.0 on nRF51822.

I'm using the pstorage SDK module for flash operations.

I've found an issue with this module, a bad memory access leading to a hardfault.

The issue occurs when the pstorage command queue is never completely empty, and the application keeps posting flash operation requests to the module while previous operations are processed.

The internal command array is used as a circular buffer, cf internal cmd_queue_enqueue() function:


/* ... */
if (m_cmd_queue.count != PSTORAGE_CMD_QUEUE_SIZE)
{
    // Enqueue the command if it is queue is not full
    write_index = m_cmd_queue.rp + m_cmd_queue.count;

    if (write_index >= PSTORAGE_CMD_QUEUE_SIZE)
    {
        write_index -= PSTORAGE_CMD_QUEUE_SIZE;
    }
    /* The request is then stored into the queue at write_index */
}

However, when a command is dequeued, the index is not checked, cf cmd_queue_dequeue():


f(m_round_val >= p_cmd->size)
{
    // Initialize/free the element as it is now processed.
    cmd_queue_init_element(m_cmd_queue.rp);
    m_round_val = 0;
    m_cmd_queue.count--;
    m_cmd_queue.rp++;
}
/* m_cmd_queue.rp is then directly used by further process_cmd() without checking its range */

I've attached a simple and naive testcase to reproduce the issue. I've been able to reproduce this issue on both PCA 10004 and custom board (you can find some logs in the archive).

I've also attached a suggested patch which solves the issue on the testcase. However, maybe more changes are needed which I'm not conscious of.

I'll be glad if someone could confirm the bug and / or the patch.

Thanks for your help !

Regards, Florent

pstorage-bad-mem-access.zip

pstorage-patch.zip

Parents
  • Hi Florent,

    Thank you for the detailed reports and patches to help reproduce the issue. Greatly appreciate your efforts.

    Your patch addresses the issue and should be fixed in subsequent SDK releases.

    One thing I would like to mention is that you are using 'raw' APIs instead of normal ones and assigning an address to me accessed yourself. Raw APIs are intended for special use cases where free manipulation of flash is needed, like the DFU. Hence I understand 'raw' mode is intentionally used.

    Thanks again!

    Regards, Krishna

Reply
  • Hi Florent,

    Thank you for the detailed reports and patches to help reproduce the issue. Greatly appreciate your efforts.

    Your patch addresses the issue and should be fixed in subsequent SDK releases.

    One thing I would like to mention is that you are using 'raw' APIs instead of normal ones and assigning an address to me accessed yourself. Raw APIs are intended for special use cases where free manipulation of flash is needed, like the DFU. Hence I understand 'raw' mode is intentionally used.

    Thanks again!

    Regards, Krishna

Children
Related