Fix heap corruption in timer subsystem #27
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The system was encountering a critical kernel panic, manifesting as: *** KERNEL PANIC (-16370) – heap corruption or invalid free The core problem stemmed from a conflict between two memory management strategies for linked-list nodes. The timer module utilized a custom static memory pool for its nodes, while the generic list manipulation functions performed their own malloc() and free() operations. This architectural mismatch led to two critical bugs. Firstly, a double-free occurred in mo_timer_destroy(). The generic list_remove() function would free a list node's memory, and then the same function would attempt to return this already-freed node to the custom memory pool. Secondly, a use-after-free vulnerability existed in the _timer_tick_handler(). If an expired timer's callback function destroyed the timer, the handler would subsequently attempt to access the now-freed timer's memory to check its auto-reload status. Fix these issues by removing the custom memory pool and unifying all node memory management under the generic list API. The _timer_tick_handler() now also re-validates the timer's existence after its callback executes to prevent accessing freed memory.
Contributor
|
Thank @visitorckw for contributing! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The system was encountering a critical kernel panic, manifesting as:
The core problem stemmed from a conflict between two memory management strategies for linked-list nodes. The timer module utilized a custom static memory pool for its nodes, while the generic list manipulation functions performed their own malloc() and free() operations. This architectural mismatch led to two critical bugs.
Firstly, a double-free occurred in mo_timer_destroy(). The generic list_remove() function would free a list node's memory, and then the same function would attempt to return this already-freed node to the custom memory pool.
Secondly, a use-after-free vulnerability existed in the _timer_tick_handler(). If an expired timer's callback function destroyed the timer, the handler would subsequently attempt to access the now-freed timer's memory to check its auto-reload status.
Fix these issues by removing the custom memory pool and unifying all node memory management under the generic list API. The _timer_tick_handler() now also re-validates the timer's existence after its callback executes to prevent accessing freed memory.