wallet2: return concrete low priority when adjust_priority fails
What changed, and why it matters
This change alters how the Monero wallet picks transaction fees when its automatic fee-estimation helper runs into problems. Previously, if the helper failed or got bad data, it returned whatever priority the caller had requested—potentially a high or urgent priority. Now it falls back to the lowest priority ('Unimportant'). This could mean users' transactions get delayed rather than overpaying, and it reduces the chance that an attacker who can feed bad blockchain data to the wallet can trick it into paying inflated fees. It is a defensive hardening fix, not a clear-cut remote exploit.
Treat as a low-risk hardening improvement. Include in normal release testing, especially for wallet fee behavior under unreliable node responses. No emergency response is warranted absent additional evidence of active exploitation.
Security signals we found
Change of failure fallback from caller-supplied priority to lowest concrete priority
Multiple early-return error paths now converge on a safe default
Exception handler now has an explicit fallback instead of falling through to return priority
Behavior aligned with existing get_base_fee fallback logic
No explicit CVE, advisory, or security label in commit or supplied references
Evidence from the diff
wallet2::adjust_priority() is called when a user selects fee_priority::Default and the wallet tries to choose an appropriate on-chain priority. The function can bail out early on several error paths: bad estimated backlog array size, failure to get the block weight limit, blockchain shorter than the lookback window, or bad block-headers response. Previously each of those paths returned the original priority argument unchanged. The patch makes every failure path return fee_priority::Unimportant (the lowest concrete priority) and adds the same fallback at the end of the catch block. The commit message says this matches get_base_fee’s handling of Default. The effect is to prevent error conditions from being treated as a reason to use a higher fee, which closes a small window in which a malicious or faulty node response could cause the wallet to overpay.
Changed components
src/wallet/wallet2.cppwallet2::adjust_priority()Monero wallet fee-priority selectionInspect captured patch +5 / −4
diff --git a/src/wallet/wallet2.cpp b/src/wallet/wallet2.cpp
index 80cc8ee..77e2f8c 100644
--- a/src/wallet/wallet2.cpp
+++ b/src/wallet/wallet2.cpp
@@ -8648,7 +8648,7 @@ fee_priority wallet2::adjust_priority(fee_priority priority)
if (blocks.size() != 1)
{
MERROR("Bad estimated backlog array size");
- return priority;
+ return fee_priority::Unimportant;
}
else if (blocks[0].first > 0)
{
@@ -8660,7 +8660,7 @@ fee_priority wallet2::adjust_priority(fee_priority priority)
uint64_t block_weight_limit = 0;
const auto result = m_node_rpc_proxy.get_block_weight_limit(block_weight_limit);
if (result)
- return priority;
+ return fee_priority::Unimportant;
const uint64_t full_reward_zone = block_weight_limit / 2;
// get the last N block headers and sum the block sizes
@@ -8668,7 +8668,7 @@ fee_priority wallet2::adjust_priority(fee_priority priority)
if (m_blockchain.size() < N)
{
MERROR("The blockchain is too short");
- return priority;
+ return fee_priority::Unimportant;
}
cryptonote::COMMAND_RPC_GET_BLOCK_HEADERS_RANGE::request getbh_req = AUTO_VAL_INIT(getbh_req);
cryptonote::COMMAND_RPC_GET_BLOCK_HEADERS_RANGE::response getbh_res = AUTO_VAL_INIT(getbh_res);
@@ -8684,7 +8684,7 @@ fee_priority wallet2::adjust_priority(fee_priority priority)
if (getbh_res.headers.size() != N)
{
MERROR("Bad blockheaders size");
- return priority;
+ return fee_priority::Unimportant;
}
size_t block_weight_sum = 0;
for (const cryptonote::block_header_response &i : getbh_res.headers)
@@ -8707,6 +8707,7 @@ fee_priority wallet2::adjust_priority(fee_priority priority)
{
MERROR(e.what());
}
+ return fee_priority::Unimportant; // fall back to low priority on failure, matching get_base_fee's handling of Default
}
return priority;
}
Why this scored 35/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.