kernel: avoid potential duplicate object in shared library/binary
What the developer wrote
Authored by Cory Fields
kernel: avoid potential duplicate object in shared library/binary
Fixes warning and potential bug whereby init_flag may exist in both
libbitcoinkernel as well as a downstream user, as opposed to being shared as
intended.
src/support/lockedpool.h:224:31:
warning: 'init_flag' may be duplicated when built into a shared library: it is mutable, has hidden visibility, and external linkage [-Wunique-object-duplication]
What changed, and why it matters
This change moves a one-time initialization flag from a header file into a source file. The warning suggested that, because the flag was defined in a header, it could end up duplicated when Bitcoin's kernel library is linked into other programs. That duplication could mean the intended single initialization runs more than once, potentially creating multiple memory managers instead of one shared instance. The patch is a defensive fix; there is no direct evidence it is currently exploitable as a security vulnerability.
Treat as a code-quality and hardening fix. Review whether any downstream builds or shared-library consumers of libbitcoinkernel could have observed duplicate initialization, and consider backporting if the project maintains stable branches. No urgent security response is indicated by the commit itself.
Security signals we found
Compiler warning about object duplication across shared-library boundaries
Singleton initialization flag moved from header to implementation file to enforce single definition
Potential for multiple LockedPoolManager instances if init_flag is duplicated
No explicit security claim or CVE in commit message
Evidence from the diff
The commit relocates the static std::once_flag init_flag and the std::call_once logic for LockedPoolManager::Instance() from the inline header definition (src/support/lockedpool.h) to a non-inline implementation in src/support/lockedpool.cpp. The compiler warning (-Wunique-object-duplication) indicated that a mutable object with hidden visibility and external linkage could be duplicated across shared-library boundaries. The concern is that LockedPoolManager’s singleton initialization could execute multiple times, producing multiple LockedPoolManager instances rather than one shared singleton. The patch is partial in a security-assessment sense: it fixes the linkage/duplication issue but the commit message frames it as a warning and potential bug, not a confirmed vulnerability.
Changed components
src/support/lockedpool.hsrc/support/lockedpool.cppLockedPoolManager singleton initializationlibbitcoinkernel shared libraryInspect captured patch +8 / −6
diff --git a/src/support/lockedpool.cpp b/src/support/lockedpool.cpp
index cbb117fc..ff3a9e69 100644
--- a/src/support/lockedpool.cpp
+++ b/src/support/lockedpool.cpp
@@ -399,3 +399,10 @@ void LockedPoolManager::CreateInstance()
static LockedPoolManager instance(std::move(allocator));
LockedPoolManager::_instance = &instance;
}
+
+LockedPoolManager& LockedPoolManager::Instance()
+{
+ static std::once_flag init_flag;
+ std::call_once(init_flag, LockedPoolManager::CreateInstance);
+ return *LockedPoolManager::_instance;
+}
diff --git a/src/support/lockedpool.h b/src/support/lockedpool.h
index 7be20823..c4966bbb 100644
--- a/src/support/lockedpool.h
+++ b/src/support/lockedpool.h
@@ -219,12 +219,7 @@ class LockedPoolManager : public LockedPool
{
public:
/** Return the current instance, or create it once */
- static LockedPoolManager& Instance()
- {
- static std::once_flag init_flag;
- std::call_once(init_flag, LockedPoolManager::CreateInstance);
- return *LockedPoolManager::_instance;
- }
+ static LockedPoolManager& Instance();
private:
explicit LockedPoolManager(std::unique_ptr<LockedPageAllocator> allocator);
Why this scored 32/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.