Skip to content

Guard getNode() NULL result in set() and operator[] - #69

Open
tropicsquirrel wants to merge 1 commit into
ivanseidel:masterfrom
tropicsquirrel:fix/getnode-null-deref-in-set-and-operator
Open

Guard getNode() NULL result in set() and operator[]#69
tropicsquirrel wants to merge 1 commit into
ivanseidel:masterfrom
tropicsquirrel:fix/getnode-null-deref-in-set-and-operator

Conversation

@tropicsquirrel

Copy link
Copy Markdown

getNode() reads and writes a shared node cache (lastNodeGot/lastIndexGot/isCached) on every access, so concurrent access from two contexts can corrupt it and make it return NULL for an in-range index. set() and operator[] then dereferenced that NULL unconditionally (getNode(index)->data) and crashed. get() already null-checks; this adds the same guard to the other two paths (set() returns false, operator[] returns a static default fallback). No change on the normal path.

Found while auditing ESP32Marauder (which vendors this lib and calls it 'thread safe') for cross-task races.

… crash)

getNode() reads AND writes a shared node cache (lastNodeGot / lastIndexGot /
isCached) on every access. If two contexts (e.g. an ISR/RX-task producer and a
main-loop consumer, as in ESP32Marauder's device lists) call into the list
concurrently, that cache can be corrupted so getNode() walks off the end and
returns NULL for an in-range index.

set() and operator[] then dereferenced that NULL unconditionally
(getNode(index)->data), crashing with a NULL write/read. get() already null-checks
(returns T()), so only these two paths crash. Add the same guard: set() returns
false, operator[] returns a static default-constructed fallback. No behavior change
on the normal (non-corrupted) path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant