Race condition: program invocation can occur before trampoline table is populated

[Alan-Jowett]

Summary

A race condition exists in _ebpf_program_type_specific_program_information_attach_provider() where program->extension_program_data is set to non-NULL before the trampoline table is updated via _ebpf_program_update_helpers(). This allows program invocation to occur with a stale or uninitialized trampoline table, leading to calls into invalid helper function addresses.

Root Cause Analysis

The Race Window

In libs/execution_context/ebpf_program.c, the attach provider function has this sequence:

// Line 532-533: Comment acknowledges the issue!
// "This should be done after the call to NmrClientAttachProvider, but _ebpf_program_update_helpers requires
// the program information to be set."

// Line 536: Unblock calls to use the program information - ENABLES INVOCATION
program->extension_program_data = extension_program_data;

// Line 538: Initialize rundown protection
ExInitializeRundownProtection(&program->program_information_rundown_reference);

// Line 543: Update helpers - POPULATES TRAMPOLINE TABLE (too late!)
if (_ebpf_program_update_helpers(program) != EBPF_SUCCESS) {
    ...
}

The Invocation Check

In ebpf_program_invoke() (line 1536):

// Check if extension_program_data is non-NULL (allows invocation)
if (ReadPointerNoFence((void* const volatile*)(&program->extension_program_data)) == NULL) {
    *result = 0;
    return EBPF_EXTENSION_FAILED_TO_LOAD;
}

As soon as extension_program_data is set to non-NULL, invocations are permitted. The JIT code will use the trampoline table to call helper functions.

Race Sequence

Time	Attach Thread	Invoke Thread (e.g., WFP callback)
T1	Set extension_program_data (non-NULL)
T2		Check extension_program_data != NULL → TRUE
T3		Get context_descriptor from extension_program_data
T4		Invoke JIT code
T5		JIT calls helper via trampoline table
T6	_ebpf_program_update_helpers() runs
T7		CRASH: Trampoline has stale/uninitialized addresses!

At T5, the JIT code uses the trampoline table, but _ebpf_program_update_helpers hasn't populated it yet (or is running concurrently). The trampoline contains either:

• Old addresses from a previous provider instance
• Uninitialized/garbage addresses
• Addresses from a driver that has since unloaded

Evidence

Crash Observed

During concurrent attach/detach testing with driver stop/start between test runs, a crash was observed:

`
Child-SP RetAddr Call Site
ffffce05

[Alan-Jowett]

Evidence (continued)

Crash Stack Trace

Child-SP          RetAddr               Call Site
ffffce05'05dc6358 fffff806'b29d6fe9     nt!KeBugCheckEx
ffffce05'05dc6360 fffff806'b29d22a8     nt!KiBugCheckDispatch+0x69
ffffce05'05dc64a0 fffff800'724b6620     nt!KiPageFault+0x468 (TrapFrame @ ffffce05'05dc64a0)
ffffce05'05dc6638 ffffd082'6bf322c5     <Unloaded_NetEbpfExt.sys>+0x6620
ffffce05'05dc6640 00000000'00000000     0xffffd082'6bf322c5

The JIT code (at 0xffffd082'6bf322c5) called into unloaded NetEbpfExt.sys code. Stack analysis showed:

ffffce05'05dc7708  fffff800'72d3f347 eBPFCore!_ebpf_link_instance_invoke_batch+0x167 
                                      [C:\ebpf-for-windows\libs\execution_context\ebpf_link.c @ 555]

This confirms the invocation path: link invoke → ebpf_program_invoke → JIT code → helper call via trampoline → stale address.

Trampoline Table Structure

The trampoline table (libs/runtime/ebpf_trampoline.c) stores helper function addresses:

typedef struct _ebpf_trampoline_entry
{
    uint16_t load_rax;
    void* indirect_address;
    uint16_t jmp_rax;
    void* address;           // ← Helper function address (points into NetEbpfExt.sys)
    uint32_t helper_id;
} ebpf_trampoline_entry_t;

These addresses are populated by ebpf_update_trampoline_table() which is called from _ebpf_program_update_helpers().

Code References

File	Lines	Description
libs/execution_context/ebpf_program.c	532-548	Race window: extension_program_data set before trampoline update
libs/execution_context/ebpf_program.c	1536	Invocation gate: checks extension_program_data != NULL
libs/execution_context/ebpf_program.c	1569-1573	JIT invocation path
libs/runtime/ebpf_trampoline.c	69-140	Trampoline table update
libs/execution_context/ebpf_link.c	555	Link invoke calls ebpf_program_invoke

Proposed Fix

The trampoline table must be populated before setting extension_program_data to non-NULL.

Option 1: Refactor _ebpf_program_update_helpers

Create a variant that accepts extension_program_data as a parameter instead of reading from program->extension_program_data:

// First: Update helpers with new addresses (trampoline populated)
if (_ebpf_program_update_helpers_with_data(program, extension_program_data) != EBPF_SUCCESS) {
    status = STATUS_INVALID_PARAMETER;
    goto Done;
}

// Then: Enable invocations (safe - trampoline is ready)
program->extension_program_data = extension_program_data;

Option 2: Use a separate "ready" flag

Add a flag that gates invocation, set it only after trampoline is updated:

program->extension_program_data = extension_program_data;
// ... update helpers ...
if (_ebpf_program_update_helpers(program) != EBPF_SUCCESS) { ... }
// Memory barrier
MemoryBarrier();
program->helpers_ready = TRUE;  // Gate invocation on this flag

Impact

• Severity: High - Can cause kernel crash (BSOD)
• Trigger: Concurrent program invocation during provider attach
• Scenario: Program attached to hook, hook invokes program while program info provider is still attaching
• Related: May be related to flaky multi_attach_concurrency_test1 failures (CI: multi_attach_concurrency_test1 flaky - socket_tests concurrency failure #4947)

Reproduction

1. Run socket_tests.exe "multi_attach_concurrency_test1" with Driver Verifier enabled on netebpfext
2. Add stop/start of netebpfext between test iterations
3. The crash occurs when a WFP callback invokes the eBPF program during the race window