Assert call being removed during compilation, causing NULL pointer dereference in ble_ll_task about infinitime

[mark9064]

Generally at least in C family languages asserts are semantically meant to be removed for release/optimised builds - they should only be used for debugging by developers and therefore don't need to be included in user facing builds.

However there's certainly some abuse of asserts in InfiniTime where error checking relies on asserts that are removed for release builds e.g verifying the size of DFU packets is done with an assert.

TLDR: Not a bug that the assert is removed, but definitely a bug if it's being hit in a debug build

[PwnVerse]

I'm entirely not sure if an assert failure has happened in the debug environment you have for testing, but during my testing, I see the assert failure happening even in the debug build.

infinitime_ins: ~/InfiniTime_ported/src/libs/mynewt-nimble/porting/npl/freertos/src/npl_os_freertos.c:42: struct ble_npl_event *npl_freertos_eventq_get(struct ble_npl_eventq *, ble_npl_time_t): Assertion `tmo == 0' failed.

Thread 4 "ll" received signal SIGABRT, Aborted.
0xf7fc4579 in __kernel_vsyscall ()
[ Legend: Modified register | Code | Heap | Stack | String ]
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$eax   : 0x0
$ebx   : 0x1bf446
$ecx   : 0x1bf4d0
$edx   : 0x6
$esp   : 0xf7fa9f60  →  0xf7a2ad00  →  0xfbad2887
$ebp   : 0xf7a2ad00  →  0xfbad2887
$esi   : 0x1bf4d0
$edi   : 0xf7faaac0  →  0xf7faaac0  →  [loop detected]
$eip   : 0xf7fc4579  →  <__kernel_vsyscall+9> pop ebp
$eflags: [ZERO carry PARITY adjust sign trap INTERRUPT direction overflow resume virtualx86 identification]
$cs: 0x23 $ss: 0x2b $ds: 0x2b $es: 0x2b $fs: 0x00 $gs: 0x63
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0xf7fa9f60│+0x0000: 0xf7a2ad00  →  0xfbad2887    ← $esp
0xf7fa9f64│+0x0004: 0x00000006
0xf7fa9f68│+0x0008: 0x001bf4d0
0xf7fa9f6c│+0x000c: 0xf7888aa7  →   mov ebp, eax
0xf7fa9f70│+0x0010: 0x00000000
0xf7fa9f74│+0x0014: 0x00000013
0xf7fa9f78│+0x0018: 0xf7a2a000  →  0x00229dac
0xf7fa9f7c│+0x001c: 0x00000006
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:32 ────
   0xf7fc4573 <__kernel_vsyscall+3> mov    ebp, esp
   0xf7fc4575 <__kernel_vsyscall+5> sysenter
   0xf7fc4577 <__kernel_vsyscall+7> int    0x80
 → 0xf7fc4579 <__kernel_vsyscall+9> pop    ebp
   0xf7fc457a <__kernel_vsyscall+10> pop    edx
   0xf7fc457b <__kernel_vsyscall+11> pop    ecx
   0xf7fc457c <__kernel_vsyscall+12> ret
   0xf7fc457d <__kernel_vsyscall+13> int3
   0xf7fc457e                  nop

On some naive analysis on my end, I feel it would be better if the assert call was replaced with a simple check for NULL event and a return. Since the application is trying to call a function pointer after the assert, it makes more sense to have a check and return instead of assert. But like I said, it can be a purely hypothetical case where the event is returned as a NULL pointer. However, hitting a null dereference in release build of the application breaks it's functionality. I trust that the developers would have made an informed decision before placing an assert here.

[mark9064]

Hmm, I don't really know enough about the structure of nimble to say more now. You probably already know, but in case not nimble is a 3rd party library InfiniTime relies on, so unless we're using it wrong the bug is external to this project. Either way, I think the assertion wouldn't be hit here because ev is not a null pointer. It is ev->fn that seems to be problematic.

The assert you have firing above is in a different location. This assert checks that any queue read from an ISR specifies a zero timeout (non blocking), as you cannot block inside an ISR. But something has in fact called the read function inside an ISR with a timeout set (i.e expecting to wait some time for an item of the queue) and may be about to unexpectedly get no item. AFAIK the LL task never runs from an interrupt context, so it shouldn't ever cause that assert to fire

[JF002]

Thanks for reporting this issue @PwnVerse !

As @mark9064 said, asserts are not compiled into the final firmware in Release build, so this is expected that you cannot find it when disassembling the binary. If you build in Debug mode, the assert should be built into the firmware.

The part of the code you mentioned is part of the NimBLE BLE stack so if you find issues and bugs in this project, they would probably be happy to receive a report as well. Please note that we are probably using an older version of the library since we haven't updated our copy for quite some time now.

I've never used Ghidra and ASAN (but I definitely would like to learn them at some point in time!). Could you give more detail about how you detected this issue? Do you run InfiniTime with ASAN on the PineTime ? Or do you run InfiniTime code on your computer?
Also, does this NULL pointer dereference happen at runtime, or is it a theoretical behavior?