Monero

This commit adds a safety check in the code that talks to USB hardware wallets (Ledger/Trezor-style devices via HID). Previously, when receiving a response in chunks, the code could keep writing past the end of a fixed-size buffer if a malicious or misbehaving device sent more data than expected. The new check stops this before each read, preventing a buffer overflow. The fix uses an assertion, which means the program will abort rather than continue in an unsafe state.

This Monero commit fixes how the wallet handles transaction public keys and address public keys so that keys with small-order or non-standard curve points (called 'torsion' points) are normalized or rejected before being used. It also tightens validation of destination addresses and makes transaction-proof logic more consistent. In plain terms, the patch closes gaps where a malformed key could confuse the wallet about who paid whom or whether a payment proof is valid.

This commit is a code cleanup: it moves the logic that removes small-subgroup 'torsion' from elliptic-curve points out of a newer, specialized module (fcmp_pp) and into the core cryptography library (crypto). The same mathematical operation is now shared by the ring signature code and the new FCMP++ code. There is no direct evidence in the commit that this fixes an active vulnerability; it looks like a refactoring to avoid duplicated constants and helper functions.

This commit changes a single error log message. Instead of printing the full invalid hash string, it now prints only the length of that string. This is a minor logging improvement and does not change any program behavior, security boundary, or data flow.

This commit fixes a security gap in how HTTP Digest authentication was validated in Monero's built-in HTTP server. Previously, a valid authentication response for one URL could potentially be accepted for a different URL. The fix now checks that the URL in the authentication response matches the URL actually being requested. The commit message itself says the practical impact for Monero's RPC use is limited.

This commit changes the order in which two internal locks are acquired in a Monero blockchain checkpoint-checking function. Lock ordering bugs are a common source of deadlocks, where two parts of the program wait forever for each other. The patch itself is very small and appears to be a partial fix rather than a complete security overhaul. There is no direct evidence in the commit that this was exploited or that it caused a concrete vulnerability, but inconsistent lock ordering in critical consensus code is a recognized reliability and potential security risk.

This commit fixes how Monero's automatic update checker validates the cryptographic hash of a downloaded update. Previously, the code only checked that the hash string was 64 characters long and contained only letters or digits. That check was flawed: a 64-character hex string with only alphanumeric characters would pass even if it was not a valid hash, and the hash was never converted into a proper internal hash object. The patch now converts the hex string into a real cryptographic hash and then back to a normalized hex form, ensuring only correctly formatted hashes are accepted. This reduces the risk that a malicious or malformed update descriptor could trick the client into trusting a bad update.

This commit adds a small convenience feature to Monero's remote procedure call (RPC) interface: the get_version response now tells callers which network the node is running on (mainnet, testnet, stagenet, fakechain, or unknown). It also refactors an existing inline network-name lookup into a reusable helper function. There is no security fix or behavior change that would allow an attacker to harm users or the network.

This commit adds stricter limits during deserialization of Monero transactions. It prevents attackers from sending malformed transactions with absurdly large numbers of inputs, outputs, or ring-member references, which could previously exhaust memory or CPU during parsing. The change moves some safety checks earlier in the process and makes them mandatory for all deserialization paths, not just the main transaction-parsing helpers.

This is a large code cleanup commit that reorganizes Monero's cryptographic headers to reduce how much code gets pulled in when including crypto.h. It removes a custom 'POD_CLASS' macro in favor of plain C++ structs, moves some hash-related functions from header files into a new source file, and updates many files to include only the headers they actually need. There is no direct security fix here, but the change touches sensitive cryptographic code and could in principle introduce subtle compilation or behavior differences.

This commit fixes a bug in Monero's cryptographic code where a specific function could return an uninitialized result when both input numbers (scalars) are zero. The fix explicitly sets the result to the point-at-infinity (the elliptic-curve equivalent of zero) before doing any work. The included test verifies this behavior. In cryptographic software, using an uninitialized or incorrect point could lead to wrong signatures, verification failures, or in some designs, security weaknesses, though the commit itself does not describe an active exploit.

This Monero commit hardens the multisig wallet code that combines partial key images from multiple signers. Previously, the code could silently build an incomplete or wrong composite key image if it received too few, too many, or duplicate partial components. The patch now rejects mismatched counts and duplicate/identity partial key images during import, and validates imported multisig data before it replaces the wallet's trusted state. A bad key image could let a malicious or buggy signer interfere with spending or detection of funds, so the change is a defensive security fix.

This Monero code change fixes a bookkeeping bug in how the node keeps track of which blockchain chunks (called 'spans') it has already asked other nodes to download. Before the fix, the code could reserve the same span twice for different peers, even with different block hashes, which could confuse download tracking and potentially allow a malicious peer to interfere with another peer's download reservation. After the fix, the node rejects any new reservation that conflicts with an existing one.

This commit adds a comprehensive sanity checker for Monero wallet transactions before they are signed or broadcast. It verifies that the transaction's outputs, inputs, fees, change address, payment IDs, and key images all match what the wallet expects. This is a defensive security improvement designed to catch malicious or buggy transaction construction—especially relevant for hardware/cold wallets and multisig—before funds can be moved to the wrong place.

This commit adds a safety cap on the number of proof elements (V) that Monero's Bulletproof and Bulletproof+ verifiers will accept. Before the change, a malformed proof could claim an unusually large number of outputs, potentially causing excessive computation, memory use, or verifier misbehavior. The patch also adds fuzz tests and unit tests to exercise this limit. It is a hardening fix rather than a confirmed exploit for theft or forgery.

This patch fixes a bug where a single wallet command could freeze the wallet-rpc handling thread forever. The bug occurs when a user asks the wallet to estimate the size of a transaction with an extremely large number of outputs (more than about one billion). The old code used a signed integer in a loop that doubles a value until it is large enough; for very large inputs this overflows, behaves unpredictably, and never finishes, causing an infinite loop. The fix changes the calculation to use unsigned 64-bit integers, which cannot overflow in the same dangerous way, and also makes the size arithmetic safer for large counts.

This commit adds a small internal optimization to Monero's transaction handling: when a transaction is pruned (stripped of some data to save space), the hash of the removed 'prunable' part is now saved inside the transaction object. This avoids having to recompute or re-supply that hash later. The change is accompanied by a unit test that verifies the cached hash matches the independently computed one. There is no direct security vulnerability visible in the diff; it appears to be a correctness/performance improvement for pruned transaction validation.

This commit fixes a crash or incorrect-behavior bug in Monero's Groestl hash function when given data that is not aligned to a 4-byte memory boundary. The old code read the input directly as 32-bit words, which can fail on some processors or compilers that require aligned memory access. The fix copies the bytes one word at a time using memcpy, which is safe for any memory address. A new unit test verifies that hashing the same bytes at different alignments produces the same result.

This commit adds size and bounds checks to Monero's serialization code, which converts blockchain data between raw bytes and usable structures. The changes prevent the code from trying to read more data than is actually available, and stop attackers from tricking the node into reserving huge amounts of memory based on a maliciously crafted message. In short, it hardens the network parsing layer against malformed data that could crash nodes or exhaust resources.

This commit fixes a low-level programming mistake in how Monero handles bytes received from outside the program. Functions that classify characters (like checking if a byte is a space, blank, letter, or digit) were being given bytes that could be interpreted as negative numbers on the systems Monero runs on. That is officially undefined behavior, meaning the program could in theory read out of bounds, crash, or misbeave on some C library implementations. The fix casts those bytes to unsigned char before passing them to the classification functions. The commit message says the bug is quiet in practice on glibc and macOS, but could be a real problem on other C libraries.

This commit is a performance optimization for Monero's RPC endpoints that fetch blocks and transactions. It replaces slow full transaction parsing with a lightweight custom parser, avoids unnecessary re-serialization, and improves how mempool transactions are returned. The changes touch security-relevant code paths (parsing untrusted transaction blobs and deciding what data to expose), but the commit itself is framed as a speedup, not a security fix. There is no direct evidence in the commit message or diff of a vulnerability being fixed, though the new parser could in principle introduce parsing bugs.

This commit is a routine performance cleanup. It reserves memory ahead of time for a list of output keys, avoids one unnecessary move of a block object, and reuses a boolean tracking vector instead of recreating it inside a loop. None of these changes alter security behavior or fix a vulnerability.

This Monero patch adds validation checks during ring signature verification to reject certain malformed 'key images.' A key image is a cryptographic fingerprint that proves a coin is being spent without revealing which coin. Before this fix, the verifier accepted some mathematically invalid key images, such as the identity point or points whose order divides a small number (torsioned points). An attacker could potentially craft such a key image to bypass the 'already spent' check, enabling double-spending of coins or denial of service against the network.

This commit only adds a new automated fuzz test for Monero's Bulletproof+ range proof verification code. It does not change any production code, cryptographic logic, or network behavior. There is no indication this commit fixes or introduces a security issue.

This commit fixes two memory-safety bugs in Monero's command-line blockchain utility tools. One bug could let a crafted saved state file cause the program to allocate an enormous vector and crash or exhaust memory. The other bug could cause the program to read a transaction input incorrectly and crash when computing ring-size statistics. These are offline analysis tools, not the live Monero daemon or wallet, so they do not directly affect running nodes or user funds.