Segmentation fault caused by call instruction

[tobashi]

We have produced an ELF file with a .text section and a maps section containing the following eBPF program:

mov64 r0, 0x0
stxw [r10-0x4], r0
mov64 r2, r10
add64 r2, 0xfffffffc
lddw r1, 0xfffffffc
call 0x1
mov64 r0, 0x1
exit

We use ./ebpf-verifier/check data.o to verify the ELF file/eBPF program and ./ubpf/vm/test -j data.o to execute.
Through fuzzing we have generated different maps sections, where PREVAIL usually catches the errors produced.
Here is an example of a data.o file that PREVAIL verifies as being correct but causes a segmentation fault in uBPF:

7f45 4c46 0201 0100 0000 0000 0000 0000
0100 f700 0100 0000 0000 0000 0000 0000
0000 0000 0000 0000 9001 0000 0000 0000
0000 0000 4000 3800 0000 4000 0700 0100

0200 0000 0400 0000 0020 0000 0100 0000
0000 0000 

          b700 0000 0000 0000 630a fcff
0000 0000 bfa2 0000 0000 0000 0702 0000
fcff ffff 1801 0000 fcff ffff 0000 0000
0000 0000 8500 0000 0100 0000 b700 0000
0100 0000 9500 0000 0000 0000 

                              002e 7374
7274 6162 002e 7379 6d74 6162 006f 626a
2d66 696c 6573 2f64 6174 612e 6f00 6d61
7073 002e 7465 7874 002e 7265 6c61 2e74
6578 7400 2e6e 6f74 652e 474e 552d 7374
6163 6b00 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
1100 0000 0400 f1ff 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0300 0300
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0300 0400 0000 0000 0000 0000
0000 0000 0000 0000 2200 0000 0300 0300
0000 0000 0000 0000 1400 0000 0000 0000
2700 0000 0300 0400 0000 0000 0000 0000
4800 0000 0000 0000 2000 0000 0000 0000
0100 0000 0200 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0100 0000 0300 0000 0000 0000 0000 0000
0000 0000 0000 0000 9c00 0000 0000 0000
4800 0000 0000 0000 0000 0000 0000 0000
0100 0000 0000 0000 0000 0000 0000 0000
0900 0000 0200 0000 0000 0000 0000 0000
0000 0000 0000 0000 e800 0000 0000 0000
9000 0000 0000 0000 0100 0000 0600 0000
0800 0000 0000 0000 1800 0000 0000 0000
2200 0000 0100 0000 0300 0000 0000 0000
0000 0000 0000 0000 4000 0000 0000 0000
1400 0000 0000 0000 0000 0000 0000 0000
0800 0000 0000 0000 0000 0000 0000 0000
2700 0000 0100 0000 0600 0000 0000 0000
0000 0000 0000 0000 5400 0000 0000 0000
4800 0000 0000 0000 0000 0000 0000 0000
1000 0000 0000 0000 0000 0000 0000 0000
2d00 0000 0400 0000 4000 0000 0000 0000
0000 0000 0000 0000 7801 0000 0000 0000
1800 0000 0000 0000 0200 0000 0400 0000
0800 0000 0000 0000 1800 0000 0000 0000
3800 0000 0100 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0100 0000 0000 0000 0000 0000 0000 0000

[Alan-Jowett]

Note:
uBPF doesn't have the same set of helper functions as the Linux kernel, so the verification by Prevail doesn't hold.

Helper #1 in uBPF is:

ubpf/vm/test.c

Line 323 in 2071abb

ubpf_register(vm, 1, "memfrob", memfrob);

Whereas helper #1 in Linux is:
https://github.com/vbpf/ebpf-verifier/blob/c0918694026bc11583e0098c956f08578ddbac02/src/linux/gpl/spec_prototypes.cpp#L164

[tobashi]

Does helper function #6 in your implementation of maps in uBPF (#170) correspond to helper function #1 in the Linux kernel?
https://github.com/Alan-Jowett/ubpf/blob/0a1860d91781c17bd2f9d82d395ac6166d120c56/vm/test.c#L461

[tobashi]

Here is the gdb output for additional detail regarding the segfault

Program received signal SIGSEGV, Segmentation fault.
bpf_map_lookup_elem_impl (map=0xfffffffc, key=0x7fffffffdd8c) at test.c:398
397        map_entry_t* map_entry = (map_entry_t*)map;
398        if (map_entry->map_definition.type == BPF_MAP_TYPE_ARRAY) {

[Alan-Jowett]

Root Cause Analysis

The Bug

The BPF program passes an invalid/malicious map pointer to a helper function, causing a segmentation fault when the helper dereferences it:

mov64 r0, 0x0
stxw [r10-0x4], r0
mov64 r2, r10
add64 r2, 0xfffffffc
lddw r1, 0xfffffffc          ; r1 = 0xfffffffc (invalid pointer!)
call 0x1                      ; bpf_map_lookup_elem(r1, r2)

GDB output confirms:

bpf_map_lookup_elem_impl (map=0xfffffffc, key=0x7fffffffdd8c) at test.c:398
398        if (map_entry->map_definition.type == BPF_MAP_TYPE_ARRAY) {
                ^^^^^^^^^^^^ Dereferences 0xfffffffc → SIGSEGV

---

Root Cause: No Map Pointer Validation

The helper function bpf_map_lookup_elem_impl directly dereferences the map pointer without validating it's a legitimate map:

// test.c:480-483
static void*
bpf_map_lookup_elem_impl(struct bpf_map* map, const void* key)
{
    map_entry_t* map_entry = (map_entry_t*)map;
    if (map_entry->map_definition.type == BPF_MAP_TYPE_ARRAY) {  // CRASH!

In the Linux kernel, the BPF verifier ensures that r1 always contains a valid map pointer before a bpf_map_lookup_elem call. uBPF doesn't have this guarantee without a verifier pass.

---

Why PREVAIL Didn't Catch This

As @Alan-Jowett noted, PREVAIL (the verifier) uses Linux kernel helper prototypes, where helper #1 is bpf_map_lookup_elem. However:

1. PREVAIL verified the program against Linux semantics
2. The lddw r1, 0xfffffffc instruction was treated as loading a map reference
3. PREVAIL doesn't know about uBPF's actual helper registration

This is a verifier/runtime mismatch - the verifier assumes one set of helpers, but the runtime has a different set.

---

Multiple Issues Here

1. Helper function doesn't validate map pointer - Should check if pointer is valid
2. No validation of map pointers at load time - ELF loader doesn't verify map references
3. Verifier/runtime mismatch - Different helper numbering between PREVAIL and uBPF

---

Proposed Fixes

Fix 1: Validate Map Pointers in Helpers (Defense in Depth)

// Maintain a set of valid map pointers
static bool is_valid_map(struct bpf_map* map) {
    for (int i = 0; i < num_maps; i++) {
        if (maps[i] == map) return true;
    }
    return false;
}

static void*
bpf_map_lookup_elem_impl(struct bpf_map* map, const void* key)
{
    if (!is_valid_map(map)) {
        // Log error and return NULL instead of crashing
        fprintf(stderr, "Invalid map pointer: %p\n", map);
        return NULL;
    }
    // ... rest of function
}

Fix 2: Validate LDDW Map References at Load Time

When loading an ELF with map relocations, verify that the map reference is valid:

// In ubpf_loader.c, when handling LDDW with src_reg=1 or 2
if (inst.src == 1 || inst.src == 2) {
    // Validate that imm refers to a valid map
    if (!vm->data_relocation_function) {
        *errmsg = ubpf_error("Map reference without relocation handler");
        return -1;
    }
    // The relocation function should validate the map exists
}

Fix 3: Consistent Helper Numbering

For fuzzing with PREVAIL, ensure the helper numbering matches:

// Use Linux kernel helper IDs
#define BPF_FUNC_map_lookup_elem 1
#define BPF_FUNC_map_update_elem 2
#define BPF_FUNC_map_delete_elem 3
// etc.

---

Severity

High - Untrusted BPF programs can crash the host process by passing invalid pointers to helper functions.

---

Acceptance Criteria

• Map helper functions validate map pointers before dereferencing
• Invalid map pointers return error instead of crashing
• Load-time validation warns about suspicious map references
• Tests cover invalid map pointer scenarios

---

Test Case

void test_invalid_map_pointer() {
    // Program that passes 0xDEADBEEF as map pointer
    uint8_t code[] = {
        // lddw r1, 0xDEADBEEF
        0x18, 0x01, 0x00, 0x00, 0xEF, 0xBE, 0xAD, 0xDE,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        // mov r2, r10; add r2, -4  (valid key pointer)
        0xbf, 0xa2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x07, 0x02, 0x00, 0x00, 0xfc, 0xff, 0xff, 0xff,
        // call bpf_map_lookup_elem
        0x85, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
        // exit
        0x95, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    };
    
    // Should NOT crash - should return error or NULL
    int result = ubpf_exec(vm, NULL, 0, &ret);
    // Either execution fails or lookup returns NULL
}

---

References

• Crash location: test.c:483 (now ~line 483)
• Helper registration: test.c:548-550
• ELF loader: ubpf_loader.c