Defining user symbols from more than one thread at the same time, with no undo transaction open, crashes the core

[WeiN76LQh]

The following issue was identified, triaged and written by Claude Fable 5.1, I have read through it to make sure the information is coherent and useful.

---

Version and Platform (required):

• Binary Ninja Version: 6.1.10594-dev
• Edition: Ultimate
• OS: macOS
• OS Version: 26.5.1
• CPU Architecture: Apple Silicon (arm64)

Bug Description:
Defining user symbols from more than one thread at the same time, with no undo transaction open, crashes the core. With four Python threads each redefining the user symbol at every function start of /bin/ls, the headless process dies on most runs, either with a segmentation fault or with libmalloc aborting on a bad free: ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED, thirteen frames below BNDefineUserSymbol.

The same loop on one thread never crashes. The same loop with define_auto_symbol in place of define_user_symbol never crashes with eight threads. And the same loop headless with the whole run inside one begin_undo_actions() / commit_undo_actions() pair never crashes either, while the GUI Python console, which runs each command inside a transaction, survived 17 runs. So the fault looks to be in the undo entry that each user-symbol call opens and commits for itself when no transaction is open. The threads do not need to touch the same addresses: giving each thread its own disjoint set of function starts still crashes 2 of 5 runs.

Steps To Reproduce:

1. Save the script below as concurrent_user_symbols.py.
2. Run it headless with any Mach-O: python3 concurrent_user_symbols.py /bin/ls
3. It dies within a second or two. If a run happens to survive, run it again; here it crashed 5 of 5 runs with four threads.

"""Redefining user symbols from several threads at once crashes the core.

Run with any Mach-O, e.g.:  python3 concurrent_user_symbols.py /bin/ls

Each thread walks every function start, undefines whatever symbol is there and defines a user
symbol with a fresh name, four times over. Four threads crash the process on most runs; the same
loop on one thread never does, and neither does the same loop with define_auto_symbol in place of
define_user_symbol.
"""
import sys
import threading

import binaryninja as bn

bv = bn.load(sys.argv[1])
bv.update_analysis_and_wait()
starts = [f.start for f in bv.functions]


def redefine(tag):
    for round in range(4):
        for start in starts:
            existing = bv.get_symbol_at(start)
            if existing is not None:
                if existing.auto:
                    bv.undefine_auto_symbol(existing)
                else:
                    bv.undefine_user_symbol(existing)
            bv.define_user_symbol(bn.Symbol(bn.SymbolType.FunctionSymbol, start, f"{tag}_{round}_{start:x}"))


threads = [threading.Thread(target=redefine, args=(f"t{i}",)) for i in range(4)]
for t in threads:
    t.start()
for t in threads:
    t.join()
print("no crash this run; run it again")

Crash frequency over five runs per configuration, headless, all with BN_DISABLE_USER_PLUGINS=1:

Threads	Operation per address	Undo transaction	Crashes
4	undefine existing, then define_user_symbol	none	5 / 5
4	define_user_symbol only	none	2 / 5
4	undefine, then define_user_symbol, each thread on disjoint addresses	none	2 / 5
4	undefine, then define_user_symbol	one, opened before the threads start and committed after they join	0 / 5
4	undefine, then define_user_symbol	one per thread	2 / 5
2	undefine, then define_user_symbol	none	0 / 5
1, with update_analysis() running alongside	undefine, then define_user_symbol	none	0 / 5
8	define_auto_symbol only	none	0 / 5

Expected Behavior:
Either the calls are safe to make from several threads, as the rest of the BinaryView API is, or the documentation says user-symbol definition must be serialised by the caller, or made inside an undo transaction. Silent memory corruption is neither.

Screenshots/Video Recording:
Not applicable; the crashing thread from the macOS crash report of one run (SIGABRT variant):

exception: EXC_CRASH SIGABRT
  0 libsystem_kernel.dylib             __pthread_kill + 8
  1 libsystem_pthread.dylib            pthread_kill + 296
  2 libsystem_c.dylib                  abort + 148
  3 libsystem_malloc.dylib             malloc_vreport + 892
  4 libsystem_malloc.dylib             malloc_report + 64
  5 libsystem_malloc.dylib             ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 76
  6 libbinaryninjacore.1.dylib         +0xe15010
  7 libbinaryninjacore.1.dylib         +0xe12810
  8 libbinaryninjacore.1.dylib         +0xe123a4
  9 libbinaryninjacore.1.dylib         +0x5a2c08
 10 libbinaryninjacore.1.dylib         +0x95b7a4
 11 libbinaryninjacore.1.dylib         +0x58ef30
 12 libbinaryninjacore.1.dylib         +0x28d45c
 13 libbinaryninjacore.1.dylib         BNDefineUserSymbol + 60
 14 libffi.dylib                       ffi_call_SYSV + 80
 15 libffi.dylib                       ffi_call_int + 1220
 16 _ctypes.cpython-313-darwin.so      _ctypes_callproc + 732
 17 _ctypes.cpython-313-darwin.so      PyCFuncPtr_call + 264
 18 Python                             _PyObject_MakeTpCall + 120
 19 Python                             _PyEval_EvalFrameDefault + 19532
 20 Python                             method_vectorcall + 152
 21 Python                             thread_run + 180

Other runs die with EXC_BAD_ACCESS / SIGSEGV in the same region of the core (frames +0xe15010 and +0xe123a4 recur). The full .ips files can be attached on request.

Binary:
Not binary-specific: /bin/ls from macOS 26.5.1 was used, and any Mach-O with a few dozen functions reproduces it.

Additional Information:
The GUI Python console does not reproduce this: the same loop pasted there survived 17 runs (16 with four threads, one with eight). Headless, it also stops reproducing when the whole run is wrapped in a single bv.begin_undo_actions() / bv.commit_undo_actions() pair (0 of 5), while one transaction per thread still crashes (2 of 5). So the fault appears to be in the undo entry each user-symbol call creates and commits for itself when no transaction is open, which is the situation in every headless script and never in the console. Python 3.13 headless with the API module from the application bundle and no user plugins loaded. The undefine-then-define pair is the shape that crashes most reliably, but define_user_symbol alone from four threads is enough.

[WeiN76LQh]

Some further findings on this, from Binary Ninja 6.1.10594 on macOS (arm64), all with user plugins disabled and no undo transaction open.

It is not specific to user symbols. Any call that records an undo action can race any other such call. The crash site is the append onto the current undo entry's action list, which is done with no lock of its own. Tracing the arm64 slice of libbinaryninjacore from that append routine back to the exported C API, over 300 BN* entry points reach it. The ones I exercised directly: BNDefineUserSymbol, BNUndefineUserSymbol, BNDefineUserDataVariable, BNUndefineUserDataVariable, BNUndefineDataVariable, BNAddUserDataReference, BNDefineUserAnalysisType, BNSetFunctionUserType, BNSetCommentForAddress, and the user tag / tag type calls.

BNUndefineDataVariable records an action even for an auto variable. BinaryView::UndefineDataVariable(addr, blacklist) builds an "UndefineDataVariable" undo action whenever a variable existed at the address, regardless of whether it was auto-discovered and regardless of blacklist. So an auto-scope call takes part in this race too.

Whether a pair crashes depends on which lock each side holds. The data-variable path takes the file's recursive lock before it starts and still holds it while it appends the action; the symbol and type paths append without it. Results, two threads of each kind walking every function start of /bin/ls, 24 passes, three runs each:

Threads	Result
user symbols beside user symbols (no lock of my own)	crash 5/5 (original report)
user symbols (serialised by my own mutex) beside undefine_data_var(addr, False)	crash 3/3
user symbols (my mutex) beside define_user_type	crash 2/3
undefine_data_var(addr, False) alone, four threads	no crash 3/3
user symbols (my mutex) beside auto define_type	no crash 3/3
user symbols (my mutex) beside auto address tags	no crash 3/3

So serialising one kind of call on the caller's side is not enough: a symbol call under the caller's lock still races a data-variable call under the core's lock, because neither lock is held by both. The only caller-side workaround that holds is one mutex around every call that can record an action.

Two ways a run dies. Either ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED when both threads grow the action vector, or EXC_BAD_ACCESS at a small address (0x20, 0x37, 0x40) inside the append routine when one thread reads a Ref the other has just moved. In 6.1.10594 arm64 the chain from the C API is 0x2528fc → 0x58ee6c → 0x95b700 → 0x5a2bd0 → 0xe12268 (the last one being the append), which shows as BNUndoActionGetSummary + 0x402c in a crash report because the core is stripped.

Minimal reproduction of the cross-kind case (the symbol side is serialised on purpose, to show that is not sufficient):

import sys, threading
import binaryninja as bn

bv = bn.load(sys.argv[1])
bv.update_analysis_and_wait()
starts = [f.start for f in bv.functions]
ints = [bn.Type.int(1), bn.Type.int(2), bn.Type.int(4), bn.Type.int(8)]
lock = threading.Lock()

def symbols(tag):
    for r in range(24):
        for start in starts:
            with lock:
                existing = bv.get_symbol_at(start)
                if existing is not None:
                    (bv.undefine_auto_symbol if existing.auto else bv.undefine_user_symbol)(existing)
                bv.define_user_symbol(bn.Symbol(bn.SymbolType.FunctionSymbol, start, f"{tag}_{r}_{start:x}"))

def data_variables(tag):
    for r in range(24):
        for start in starts:
            bv.define_data_var(start, ints[r % 4])
            bv.undefine_data_var(start, False)

threads = [threading.Thread(target=symbols, args=("s0",)), threading.Thread(target=symbols, args=("s1",)),
           threading.Thread(target=data_variables, args=("d0",)), threading.Thread(target=data_variables, args=("d1",))]
for t in threads: t.start()
for t in threads: t.join()
print("no crash")