Monero

This patch fixes a type-safety bug in Monero's peer-to-peer networking code. The send() function used to return an integer where -1 meant failure, 0 meant 'connection not found', and 1 meant success. Some callers treated any non-zero value as success, so a -1 failure could be misread as success. The patch changes send() to return a proper true/false boolean so failures cannot be misinterpreted. The commit message explicitly points to make_payload_send_txs as an example of such a caller.

This change improves the user experience when unlocking a Monero wallet that is paired with a hardware wallet (like Ledger or Trezor). Previously, if the hardware wallet timed out or disconnected during unlock, the software would silently loop back to the password prompt without explaining why. Now it prints a clear error message telling the user to check that the hardware wallet is connected and unlocked. This is a minor reliability/usability fix, not a fix for a serious security vulnerability.

This commit strengthens Monero's built-in random number generator so that if an attacker later steals the generator's internal memory state, they cannot easily figure out what random numbers were generated in the past. It also locks that sensitive state in RAM so it cannot be swapped to disk. The change is a defensive hardening patch, not a fix for an active exploit, and the exact real-world attack it prevents is not described in the commit materials.

This commit updates Monero's Guix reproducible-build scripts to add support for Rust dependencies needed by an upcoming feature called FCMP++. It does not change wallet logic, consensus rules, or network code. The changes are build-system plumbing: vendoring Rust crates, configuring Cargo to use them offline, and exposing the Rust standard library source. There is no direct evidence this commit fixes or introduces a security vulnerability.

This commit fixes a privacy and security bug where Monero wallets ignored the user's --no-dns setting and still performed DNS lookups for OpenAlias addresses (human-readable names like donate.getmonero.org). Now, when DNS is disabled or the wallet is offline, the wallet will not make those DNS queries. This prevents accidental network leaks and reduces the chance that a malicious or monitored DNS server could manipulate address resolution.

This commit adds a safety check in Monero's network code that verifies an incoming response matches the command that was originally requested before the response is accepted and buffered. Without this check, a malicious or misbehaving peer could potentially send an unexpected response that the software would process incorrectly, possibly causing confusion, resource waste, or protocol errors. The patch is defensive and partial—it validates the command but does not by itself fix a fully demonstrated exploit.

This commit adds a simple 'clear' command to the Monero command-line wallet that clears the terminal screen, similar to typing 'clear' in a shell. It is a user-interface convenience feature with no security relevance.

This commit adds an early safety check to Monero's transaction parsing code. It rejects transactions that contain an impossibly large number of 'key offsets'—the references that identify which previous transaction outputs a transaction is spending from. The limit is based on the maximum allowed transaction size, so any transaction exceeding it cannot be valid anyway. The change is defensive and prevents malformed or oversized transaction data from being processed further.

This commit only fixes spelling and wording in code comments (for example, changing 'Minimal' to 'Minimum' and 'lock' to 'unlock' where the comment was describing the wrong function). No actual program logic, function behavior, or security mechanism was changed.

This patch tightens up how Monero's transaction pool records when to next re-broadcast relayable transactions. Previously, a database transaction was held open while iterating over all candidate transactions; now the lock is taken only when there are actual timestamp updates to write, and each update is wrapped in its own try/catch so one failing update does not abort the whole batch. The commit title says it fixes a 'write abort' and improves locking. The change reduces the chance that a transient database error or a single bad metadata update rolls back every scheduled relay update, which could have caused transactions to be re-relayed too soon or too late and potentially leak timing information about Dandelion++ routing.

This Monero patch fixes how the node keeps track of other peers' blockchain heights and who gets to receive new transactions. Previously, a node might think a peer was behind and stop sending it transactions, even when the peer actually had the latest block. The patch updates the peer's height when a new block is validated and allows a small two-block tolerance when choosing transaction-relay peers. The main risk if this were buggy or absent is degraded network propagation: transactions or blocks might spread more slowly, which can hurt network health and potentially be exploited to gain timing advantages (for example, in mining or double-spend scenarios).

This commit fixes a display-only bug in Monero wallets. When a transaction is split into multiple parts, the wallet was showing the change address from the first transaction piece, even if that piece had no change. The fix makes it show the first piece that actually has change. The commit message says misleading display is the only effect because foreign change addresses are already rejected during signing, so no money could be sent to an attacker's address.

This commit simply removes header files that were included in source code but not actually needed. It is a routine cleanup with no functional change to the Monero software and no security relevance.

This commit fixes several issues flagged by static analysis tools. Most changes add missing virtual destructors to C++ interface/base classes and remove unused function declarations. Missing virtual destructors can cause subtle memory bugs when objects are deleted through a base-class pointer, but the commit does not show any active crash or exploit path. It is a cleanup/hardening patch rather than a fix for a known active vulnerability.

This change adjusts how a Monero wallet fetches block hashes during its fast refresh mode. Previously, fast_refresh could keep pulling hashes without respecting the caller's max_blocks limit, which could make a single refresh call run for a very long time and appear unresponsive. The patch caps the number of hash pulls per refresh call and lets the wallet resume later, improving responsiveness. It is a robustness/usability fix rather than a clear-cut security vulnerability, though unbounded network loops can sometimes be abused to delay or hang wallet operations.

This commit refactors how Monero's peer-to-peer networking layer tracks active connections. Previously, the code stored raw pointers to connection objects in a central map and used manual reference counting (add_ref/release) to try to prevent those objects from being destroyed while still in use. The patch replaces that with std::weak_ptr and std::shared_ptr, so the map only holds non-owning weak references and the connection objects are kept alive automatically by shared_ptr ownership. This is a defensive hardening change that reduces the risk of use-after-free, double-free, and race-condition crashes in network handling. It is not an obvious remote exploit by itself, but it fixes a class of memory-safety bugs that could be triggered by malicious or unstable peers.

This commit removes several database checks that Monero performed before forwarding a newly received block to other peers. Previously, the node verified that it had all the block's transactions and that no blockchain reorganisation had happened. Now it relays the block immediately with fewer checks. The stated goal is performance, but the change could allow invalid or stale blocks to be relayed more easily, potentially contributing to network confusion or denial-of-service. There is no direct evidence in the commit that this fixes a known security bug or that it introduces an exploitable vulnerability.

This change fixes a logic bug in Monero's blockchain handling. Previously, when the software saw a block it already knew about, it would simply mark it as 'already exists' and move on, even if that block had previously been flagged as invalid. After the patch, if a known-invalid block is seen again, the verification is now correctly marked as failed. This prevents an invalid block from being treated as harmless on re-submission and could stop certain denial-of-service or chain-integrity attacks.