Monero

This change blocks a specific command—signing unsigned transaction files—from being used when a Monero wallet's private keys live on a hardware device (Ledger/Trezor). Before the patch, the software apparently allowed users to attempt this operation, which hardware wallets do not actually support. The patch now returns a clear error instead of proceeding. The risk is that a user or third-party tool could be misled into thinking a transaction was properly signed when it was not, potentially causing loss of funds or a failed/confused workflow. No exploit code is shown in the commit.

This Monero patch changes how block templates are built for restricted RPC users. Before, a remote user calling the get_block_template RPC on a restricted node could receive a block template containing sensitive transactions—specifically transactions that were relayed privately (such as Dandelion++ stem transactions). The patch adds a flag so restricted RPC callers get a template that only includes publicly broadcast transactions, while local/unrestricted callers still get the full template. This reduces information leakage about pending private transactions to untrusted RPC clients.

This is a tiny performance tweak in Monero's network code. It changes one function call so that a batch of downloaded blocks is moved rather than copied into an internal queue. There is no security fix here and no indication it addresses a vulnerability.

This is a one-line bug fix in Monero's command-line wallet. The 'sweep_account' command, when asked to sweep all subaddresses of a different account than the one currently selected, accidentally looked at the wrong account's list of subaddresses. This could cause some funds to be left behind or the command to wrongly report that the target account had no spendable balance. It does not let an attacker steal funds; it is a user-facing functional bug that could surprise a wallet user.

This patch fixes a bug in how Monero wallets build key images for transaction outputs they own. When a transaction contained an invalid extra public key, the wallet would misalign its internal list of cryptographic derivations. This caused the wallet to either look at the wrong entry or fail to recognize its own output, preventing it from creating a key image. Because anyone can craft a transaction with such an invalid key, this could be used to stop a wallet from spending its own funds. The fix pads the failed derivation with a placeholder so the list stays aligned with output indexes.

This change alters how Monero processes batches of incoming blocks. Previously, if any block in a batch was already known, the code would skip fully parsing the remaining blocks. Now it parses all blocks regardless. This could have hidden a bug where incomplete parsing led to inconsistent state, but the patch itself is small and the exact security impact is not stated by the vendor.

This commit fixes a bug in how Monero nodes request blocks from peers during blockchain synchronization. Before the fix, a node could accidentally reserve the same range of blocks twice from different peers, wasting bandwidth and potentially causing synchronization confusion. The fix adds a check to skip over any block ranges that are already reserved. A new test confirms the behavior.

This Monero commit changes how a node calculates the size of upcoming block batches during sync. Previously, when a peer sent 'pruned' blocks (a compressed form), the node did not fully count those blocks toward its sync-size budget and only checked that their reported weight was non-zero. The patch makes the node use the pruned blocks' reported weights in its size calculations and verifies those weights against data already stored in its own chain. The main effect is to prevent a malicious or buggy peer from making the node request far more data than expected, which could slow or disrupt syncing. It is a hardening/DoS-mitigation change rather than a direct coin-theft bug.

This Monero commit rewrites how the peer-to-peer block download queue is limited. Instead of capping the number of 'spans' (batches) of blocks, it now caps the total number of queued blocks based on the measured download speed and a user-configurable target time. The change also fixes a couple of small arithmetic edge cases, such as avoiding division by zero when measuring microseconds and guarding against invalid or infinite block rates. The commit message and diff do not describe any security bug; it reads as a performance and robustness improvement to sync behavior.

This commit removes the entire translation/internationalization system from the Monero command-line tools. It deletes translation files, build scripts, documentation, and the code that loaded and applied translated text. The remaining code now always displays English text. There is no security fix or vulnerability here; it is a feature-removal cleanup change.

This commit is a routine cleanup that removes unused functions, type aliases, and unreachable code from Monero's core blockchain and transaction-pool modules. The removed code had no callers, so the change cannot be used to attack the network or users. It is purely a maintenance refactor.

This commit is titled as a cleanup of a single RingCT function (proveRctCLSAGSimple), but the supplied diff is actually a massive repository import/addition of 1,360 files (696,994 insertions) including the entire Monero codebase, build system, CI workflows, documentation, tests, and submodules. There is no actual code change to proveRctCLSAGSimple visible in the provided diff. No security-relevant change is present in the materials supplied.

This patch changes how Monero's peer-to-peer networking layer handles bad or rejected messages. Previously, when a message handler decided to drop a peer, it often returned a generic success-like code (1) or a 'handler not defined' error. The patch makes these handlers return a specific connection error code, and makes the lower-level protocol stop processing further buffered messages from that peer when it sees a fatal error. This prevents a misbehaving or malicious peer from forcing the node to keep handling queued messages after the node has already decided to disconnect. The change also ensures notifications (one-way messages) return OK instead of a handler-not-defined error when a command is filtered, avoiding spurious errors.

This commit fixes a simple arithmetic bug in how long a transaction has been waiting in the memory pool ("time in pool") was calculated. The old code subtracted the current time from the receive time in the wrong order, which could produce a very large, nonsensical age value instead of a small positive number. The fix ensures the age is always the current time minus the receive time, or zero if the clock somehow runs backward. This is a correctness fix for statistics/ranking of pending transactions, not a direct funds-theft or code-execution vulnerability.

This commit adds an overflow check when the Monero wallet calculates transaction fees from a transaction's weight. Before the patch, multiplying a large 'weight' value by a non-zero 'base_fee' could silently wrap around to a tiny number, potentially causing the wallet to propose an incorrect (possibly far too low) fee. The fix now throws an internal wallet error instead of silently producing a wrong result.

This commit changes how Monero's Trezor hardware wallet integration handles one specific error. Previously, if a user cancelled the view-key export on their Trezor device, the code fell through to a generic 'Get secret keys exception' message and returned false. Now it immediately throws a clearer error: 'Key export rejected on device.' This is a user-experience and diagnostic improvement, not a fix for an exploitable security flaw.

This commit changes how Monero hashes certain internal data types. Previously, some types were hashed using a simple identity function that directly used raw bytes as the hash value, which can cause many items to land in the same hash-table bucket and potentially leak information through timing or collision patterns. The patch replaces that with SipHash-2-4, a keyed, cryptographically designed hash function, using a secret random key generated at startup. This is a defensive hardening change; the commit message frames it only as a performance/distribution optimization, not as a security fix.

This commit adds three new cryptographic generator points (named T, U, and V) to Monero's code. These are special numbers used in a new privacy feature called FCMP++. The commit also adds helper functions to recreate and access these generators. There is no indication of a security bug or vulnerability in this change; it is a straightforward addition of constants needed for future protocol work.

This commit adds two new math helper functions that convert points between two related elliptic-curve formats used in cryptography (Ed25519 and X25519). It is a pure addition of utility code; there is no bug fix, no change to existing behavior, and no indication it addresses a security flaw. The code includes a safety check that rejects the special 'identity' (zero) point, which is a sensible defensive measure.

This is a one-line build-system change that adds a missing library dependency ('wire') so another component can compile and link correctly. There is no indication it fixes a security vulnerability; it appears to be a routine build fix.

This commit removes compiler directives that forced certain cryptographic data structures to be packed tightly without padding, and replaces some direct multi-byte memory reads with safer memcpy operations. On some processors, reading a multi-byte value from a memory address that is not aligned to that value's size can cause a crash or reduced performance. The change makes the code safer and more portable across different CPU architectures, but it does not appear to fix an exploitable remote vulnerability in the Monero network itself.

This commit fixes the way a Monero cryptographic function for ARMv8 processors describes its inline assembly code to the C compiler. Previously, the assembly block did not properly tell the compiler which memory and CPU registers it reads and writes. This can lead to subtle bugs where the compiler optimizes code incorrectly around the assembly, potentially causing wrong hash results or memory corruption on ARMv8 devices. The fix adds proper input/output constraints and a clobber list so the compiler knows exactly what the assembly touches.

This commit adds a type check in Monero's JSON deserialization code. Before the fix, when reading a RingCT signature from JSON, the code assumed the 'prunable' field was a JSON object and accessed it directly. If someone supplied a non-object value (like a number or string), the code could read memory incorrectly or crash. The patch now throws a clear error if the type is wrong.

This commit adds new code for an upcoming Monero privacy feature called FCMP++. It creates a helper function that converts an output's public key and commitment into a special three-part tuple used by the new system. The commit is defensive in nature: it carefully clears mathematical 'torsion' from points, rejects identity points, and explicitly avoids a subtle double-spend risk that could occur if the wrong version of a key were used around a network upgrade. There is no indication this commit fixes an active bug or vulnerability; it appears to be a building block for future functionality.

This Monero wallet patch changes how the wallet decides whether an encrypted payment ID is real or a dummy placeholder. Previously, the wallet relied on destination address data (cd.dests), which could be manipulated by a malicious signer or loaded transaction to make a real payment ID look fake, or a fake one look real. The patch now derives that status directly from the transaction's extra field, where the payment ID is actually stored, and adds a consistency check. This is a security fix for a potential information leak or user deception during multi-step transaction signing.