gpoulios opened a new pull request, #16713: URL: https://github.com/apache/nuttx/pull/16713
## Summary libc lib_idr maintains 2 RB trees to efficiently handle node allocations. Removed nodes are not freed, but rather added to the "removed" RB tree, for potential re-use during subsequent allocations. `idr_destroy()` would loop over the nodes of the "removed" and "alloced" RB trees, freeing them but not removing them from the trees. From the perspective of the RB tree those nodes would remain valid, while in fact, they were free memory, potentially reallocated for other purposes, or otherwise overwritten with allocator metadata. This would cause (seemingly random) memory corruption crashes during calls to `idr_destroy()` triggered by the RB tree code trying to access linkage fields (`left`, `right`, `parent`) from the free'd nodes. Fix this by removing the nodes before freeing them. ## Impact For users of lib_idr (or users of optee or v9fs), this might solve (seemingly random) crashes, and will definitely make it more reliable during destruction. ## Testing I have observed this issue when using the optee driver with an app I cannot share. Every time I isolated `idr_alloc()/remove()` sequences to re-produce the issue in a neutral context, the bug didn't manifest. I suspect this might have to do with high memory pressure causing the allocator to re-arrange free chunks or something. So, while I unfortunately cannot share reproduction code, the issue & fix should be relatively obvious. My crashing use-case no longer crashes after this patch. All other tests ran in arm64 NXP iMX93 SoC generate positive results. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
