Bundled ORT cache installation is unbounded and races concurrent loaders #18
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found during independent exact-head review of breadsearch PR13 at
354343c58e. Confidence: high. breadmill/src/embed.rs:97-105 reads arbitrary existing cache paths with fs::read before checking regular-file type or size, creates directories with inherited umask, and lines 117-123 unlink installed shared libraries before renaming without serialization. Isolated real-binary reproduction: precreate a FIFO at cache/breadsearch/runtime/libonnxruntime.so.1.28.0, start with cached real model and empty roots; status stays model_ready=false/model_error=null because loader blocks opening FIFO. With umask 000, successful provisioning creates both executable-code libraries mode 0666 and runtime directory mode 0777. Concurrent installers can remove a library between another loader check and dlopen, or race exists/remove causing ENOENT. Evidence: /tmp/opencode/pr13-fmd0vs8q and review worktree ~/.worktrees/breadsearch/fix/astra-review-pr13-354343c. Fix in existing PR13: owned private directory and regular-file/no-follow checks, bounded comparison, serialized/atomic publication without unlink gap, tests for concurrent first install/repair and unsafe cache entries. README.md:164-168 also still claims system linker discovery without ORT_DYLIB_PATH, contradicting new explicit bundled default. No merge performed.