Null pointer dereference in fellow_busy_body_seg_next due to fbo->body_seglist == NULL
From #32 (comment 1625347355) reported by @jlcox70
Signal 11 (Segmentation fault) received at 0x8 si_code 1
...
0x7f8624bd6720: vext_cache/libvmod_slash.so,xogidlnt.so(fellow_busy_obj_getspace+0x300) [0x7f8624bd6720]
Annotated objdump snippet with fellow_busy_body_seg_next()
inlined into fellow_busy_obj_getspace()
:
// PANIC <-
4d6f0: 49 8b 46 30 mov 0x30(%r14),%rax // AN(fcs->alloc.size);
4d6f4: 48 85 c0 test %rax,%rax
4d6f7: 0f 84 a7 07 00 00 je 4dea4 <fellow_busy_obj_getspace+0xa84>
4d6fd: 49 8b 56 38 mov 0x38(%r14),%rdx // fcs->len
4d701: 48 39 d0 cmp %rdx,%rax
// jmp if (fcs->len < fcs->alloc.size)
4d704: 0f 87 16 04 00 00 ja 4db20 <```
+0x700>
// assert(fcs->len == fcs->alloc.size);
4d70a: 0f 85 f8 0a 00 00 jne 4e208 <fellow_busy_obj_getspace+0xde8>
// fellow_busy_body_seg_next
4d710: 81 3b 32 a1 04 85 cmpl $0x8504a132,(%rbx) // FELLOW_BUSY_MAGIC
4d716: 0f 85 04 08 00 00 jne 4df20 <fellow_busy_obj_getspace+0xb00>
4d71c: 48 8b 6b 50 mov 0x50(%rbx),%rbp // fcsl = fbo->body_seglist;
4d720: 48 8b 45 08 mov 0x8(%rbp),%rax // <===
4d724: 48 85 c0 test %rax,%rax
If I analyzed the code correctly, the panic was caused by fbo->body_seglist == NULL
here: The segmentation violation was at address 0x8
, which is the offset of the fdsl
member:
(gdb) p offsetof(struct fellow_cache_seglist, fdsl)
$7 = (struct fellow_disk_seglist **) 0x8
The OP reported that this issue had not been triggered since they stopped used a shared memory cache, so the likely cause is incomplete error handling for a seglist allocation.
Edited by Nils Goroll