feat(kernel): Enforce uxListRemove Precondition with Assertion

[kernelpoetlaureate]

Right now, uxListRemove() blindly dereferences pxItemToRemove->pxContainer to get the parent list. If an item is removed twice, the second removal leads to a NULL dereference and potentially very tricky bugs—memory corruption or random hard faults that show up far from the original mistake.

---

Reproducing the Issue

This minimal test case demonstrates the bug clearly:

void vDemonstrateDoubleRemoveFailure( void )
{
    List_t xMyList;
    ListItem_t xMyItem;

    vListInitialise( &xMyList );
    vListInitialiseItem( &xMyItem );

    // Insert the item—everything valid so far.
    vListInsert( &xMyList, &xMyItem );

    // First removal: valid. The container is now NULL.
    uxListRemove( &xMyItem );

    // Second removal: not valid. pxContainer is NULL—boom.
    uxListRemove( &xMyItem );
}

---

The Fix

Simply adding this line at the beginning of uxListRemove() makes the contract explicit:

configASSERT( pxItemToRemove->pxContainer != NULL );

This stops the function immediately if it's called with an invalid state, turning a subtle landmine into a clear, actionable failure.

---

Impact

• Performance & Code Size: None at all in production—configASSERT compiles away when assertions are disabled.
• Debuggability: Huge win. It turns an obscure crash into an instant diagnostic message.
• Compatibility: 100% backward-compatible. This only catches code that was already incorrect.

[aggarg]

FreeRTOS List is internal data structure not intended for application use. The List API may change even between minor versions. Are you experiencing any issues while using FreeRTOS's public APIs?

[sonarqubecloud]

Quality Gate passed

Issues
27 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud