Threats Tagged 'crates-io'

The aarch64 implementations of the Rust crate 'cmov' for the functions Cmov and CmovEq incorrectly handle high bits of registers when loading values smaller than the register size. This causes conditional move operations to produce incorrect results if the high bits are set, due to assumptions about zero-extension that do not hold. The issue affects versions >=0.1.1 and <0.5.4 of the cmov crate. Proof-of-concept tests demonstrate that conditions truncated to smaller types still retain high bits in registers, causing wrong conditional selections. The bug is specific to aarch64 architecture and arises from inline assembly behavior. No known exploits are reported, and the impact depends on how the affected functions are used in calling code.

A vulnerability in zebrad up to and including v4.4.1 allows an authenticated RPC client to cause a denial of service by sending a getblocktemplate request with a non-ASCII LongPollId. The RPC handler performs byte-index slicing on the LongPollId string, which panics in Rust when multi-byte UTF-8 characters are present, terminating the entire node process. This affects nodes with RPC enabled via a TCP address and requires attacker authentication to the RPC endpoint. The issue is fixed in zebrad 4.5.0 and zebra-rpc 8.0.0.

A vulnerability in zebrad up to version 4.4.1 allows oversized getblocks and getheaders locator vectors, up to approximately 65,535 entries instead of the protocol limit of 101. This causes excessive CPU usage by occupying blocking-pool threads during chain lookup operations. Exploitation requires significant attacker bandwidth and multiple Sybil peers, limiting real-world impact. The issue is patched in zebrad 4.4.2 by enforcing the correct locator size limit. No specific workaround is needed as existing backpressure mechanisms mitigate the impact.

A vulnerability in zebrad up to v4.4.1 allows an authenticated RPC client to cause a denial of service by sending a crafted Sapling receiver in the z_listunifiedreceivers RPC call. The RPC handler panics due to improper error handling of invalid Sapling receiver data, causing the entire node process to abort. This can be exploited repeatedly to keep the node offline. The issue is fixed in zebrad 4.5.0 and zebra-rpc 8.0.0.

zebrad versions up to and including 4.4.1 are vulnerable to a denial of service condition where a single unauthenticated inbound P2P peer can saturate all mempool transaction admission slots by advertising fake transaction IDs. This prevents honest peers and local RPC clients from submitting transactions to the mempool, although block validation and chain synchronization remain unaffected. The vulnerability arises from lack of per-peer slot accounting, no overload signaling, and no misbehavior attribution. The issue is fixed in zebrad 4.5.0 by adding per-peer queue limits and proper overload signaling.

Zebra versions up to and including v4.4.1 have a vulnerability where the P2P codec reserves virtual buffer capacity based on an attacker-claimed body length before handshake completion. This reservation affects only virtual address space without committing physical memory, and existing connection limits and handshake timeouts mitigate practical exploitation. The issue is addressed by deferring large buffer reservations until after the handshake or capping pre-handshake message reservations. The impact is minimal and does not cause measurable denial-of-service.

Zebra versions up to and including 4.4.1 are vulnerable to a block suppression attack via poisoned block bodies that share a header hash with valid blocks. A remote unauthenticated peer can cause the node to cache a rejected block hash, leading the node to treat the later valid block as a duplicate and stall progress at a specific block height. This results in the node being unable to advance until restarted or a rare reorganization occurs. The vulnerability exploits the way Zebra caches block hashes before validation and does not remove them on validation failure. The issue is patched in Zebra 4.4.2.

A consensus divergence vulnerability exists in zebrad up to and including v4.4.1 due to an incorrect P2SH sigop counting implementation in its pure-Rust disabled-opcode parser. This causes Zebra nodes to accept blocks that zcashd nodes reject when the block-wide MAX_BLOCK_SIGOPS threshold is exceeded on one side but not the other. An attacker can exploit this by broadcasting transactions with malicious redeem scripts containing disabled opcodes followed by sigops, causing a chain split between Zebra and zcashd validators. The issue is patched in Zebra 4.4.2 by routing the P2SH sigop counter through the same C++ FFI used by the legacy sigop counter. No configuration workaround exists; upgrading is required to remediate.

Zebra versions up to and including v4.4.1 are vulnerable to a sync restart poisoning attack via unauthenticated peers. A malicious peer can cause the node to repeatedly restart its sync process by sending blocks with a coinbase height far above the local tip, triggering a global sync restart delay of 67 seconds each time. This attack cancels all in-flight downloads from honest peers, significantly degrading sync progress without crashing or corrupting the node. The vulnerability is patched in Zebra 4.4.2, which improves error handling by banning offending peers and preventing global sync restarts. No configuration workaround exists; mitigation requires upgrading to the fixed version or maintaining a diverse honest peer set.

Zebra nodes running zebrad up to and including version 4.4.1 are vulnerable to a panic caused by an integer overflow during transparent address balance calculation when processing consensus-valid blocks containing many self-spends to the same address. This panic causes the node process to abort and creates a persistent halt that recurs on restart, disrupting node operation until patched. The issue is fixed in Zebra version 4.4.2 by changing the balance update logic to process credits and debits together per transaction. No workaround exists other than upgrading.