Enqueue wait handle free to epoch work item during set_wait_handle#5307
Draft
mikeagun wants to merge 5 commits into
Draft
Enqueue wait handle free to epoch work item during set_wait_handle#5307mikeagun wants to merge 5 commits into
mikeagun wants to merge 5 commits into
Conversation
F-001 (Critical): _ring_buffer_notify_consumer reads kernel_page->wait_event without synchronization while set_wait_handle/destroy can concurrently replace and dereference the old event object, causing a use-after-free. Fix: Reader reads the pointer exactly once via ReadPointerNoFence (zero overhead, matching ebpf_program.c:1576 pattern). Writer atomically swaps via InterlockedExchangePointer, then defers ObDereferenceObject of the old event to an epoch work item so in-flight readers (BPF programs within an epoch) can safely call KeSetEvent before the event is freed. F-007 (Medium): Callers pass ebpf_handle_invalid to clear the wait handle, but ObReferenceObjectByHandle fails on the invalid handle and the function returns early without clearing or dereferencing the old event — leaking the kernel event object reference. Fix: Check for ebpf_handle_invalid before ObReferenceObjectByHandle. When clearing, swap in NULL and let the deferred-deref logic release the old event. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Verify that ebpf_map_set_wait_handle_internal with ebpf_handle_invalid properly clears the old event reference (returns EBPF_SUCCESS instead of EBPF_INVALID_ARGUMENT), and that a new handle can be set afterward. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Stress test: producer thread writes ring buffer records while another thread rapidly sets and clears the wait handle. Exercises the ReadPointerNoFence + epoch-deferred ObDereferenceObject synchronization. Run for 1-2 seconds to maximize race window coverage. Added to both api_test.exe (kernel test) and unit_tests.exe (usersim). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
ebpf_ring_buffer_set_wait_handle runs inside an epoch via the protocol handler. The previous OOM fallback called ebpf_epoch_synchronize, which waits for the current epoch to retire — but the caller is an active reader in that epoch, causing self-deadlock. Fix: probe-allocate an epoch work item before the swap. If allocation fails, fail the operation before modifying state. After the swap, allocate with the real old_wait_event context. If the post-swap allocation fails (extremely unlikely after probe success), log and leak the event reference rather than risk deadlock. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
Describe the purpose of and changes within this Pull Request.
Please reference an issue with a keyword such as Fixes #abc, Closes #xyz, etc., so the work can be tracked.
Testing
Do any existing tests cover this change? Are new tests needed?
If new tests were added:
Documentation
Is there any documentation impact for this change?
Installation
Is there any installer impact for this change?