Monero

This patch fixes a bug in the Monero daemon's 'start_mining' command. Previously, when a user started mining to a human-readable address (like a domain name), the code asked for a DNSSEC-validated lookup but then ignored whether DNSSEC actually succeeded. That could let an attacker on the network tamper with the DNS response and redirect mining rewards to their own wallet. The patch now rejects the command if DNSSEC validation fails.

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 changes only the spacing in a command-line prompt message, removing one extra space before the '[y/N]' confirmation prompt. It has no security relevance.

This commit only renames two CSV column headers in the Monero wallet's export_transfers output from 'amount' to 'transaction amount' and 'destination amount' to make them less confusing. No numbers, logic, or behavior changed.

This commit adds a new wallet API function that exposes more details when verifying a signed message, such as which key was used and which signature version was detected. It does not change existing behavior; the old simple true/false check still works exactly as before. There is no indication this fixes a security bug or introduces a vulnerability.

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 fix corrects a Monero wallet bug where a user could generate a cryptographic 'reserve proof' claiming they still owned money that they had already committed to spending. Before the patch, the wallet only excluded outputs from the proof once the spending transaction was confirmed on the blockchain. Because the wallet marks outputs as spent earlier—when the transaction is first submitted to the network—a user could honestly but incorrectly prove reserve over outputs that would disappear as soon as the pending send confirmed. The patch makes the wallet treat pending-spent outputs as unavailable and checks the exact outputs selected for the proof rather than a broader balance figure that could include pending change.

This commit fixes a typo in two user-facing error messages, changing 'LDMB' to 'LMDB'. It does not change any program logic, database handling, or security behavior.

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 is a tiny user-interface wording change in Monero's command-line wallet. It changes when and how a 'suggested threshold' of confirmations is shown to the user when viewing a transfer. Previously, the threshold was shown whenever it was greater than zero. Now, it is only shown when the actual number of confirmations is still below that threshold. Once the threshold is reached, the extra text is hidden. This is a cosmetic change, not a security fix.

This change fixes a CSV export bug in Monero's command-line wallet. User-written notes attached to transfers were written into the export file without surrounding quotes, while other fields were quoted. If a note contained a comma, the exported CSV would have extra columns, and if it contained a quote, the file could become malformed. This is a data-integrity/formatting fix rather than a code-execution vulnerability, but it could mislead users or break import into spreadsheet software.

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.