Advisories for Cargo/Ckb package

Tx-pool verify transaction which inputs' script contains load_cell_data_hash is nondeterministic

Adversary can create message which compressed size is less than the package limit but the decompressed length is very large such as 1G. It will cost the node many memories to process the network messages, and on the system with less than 1G memory, the process is killed directly because of out of memory error.

There's a bug in the pool statistics that when conflicting transactions are removed from the pool, they are not subtracted from the statics. Finally, the transaction pool keeps full and reject all transactions.

The faulty nodes will reject transactions which calls load_cell_data syscall but the input cell is still in the mempool. They also ban other nodes and cause the network separation.

CKB process will panic when received malformed p2p message because of snappy, which is used to compress network messages

via bounty@nervos.org There are multiple type conversions in ckb that unsafely cast between byte pointers and other types of pointers. This results in unaligned pointers, which are not allowed by the Rust language, and are considered undefined behavior, meaning that the compiler is free to do anything with code. This can lead to unpredictable bugs that can become security vulnerabilities. Some of the bugs here could potentially lead to buffer …

The P2P protocols lack of rate limit. For example, in relay protocol, when a node receives a broadcasted tx_hashes, it will mark it in memory to avoid duplicated requests. code → . It is easy to establish a DoS attach by generating random tx hashes.

Adversary can initiate DOS attack by broadcasting two consecutive blocks with timestamps in the future.

The p2p discovery protocol assumes that the peer IP must be valid IPv4 address.

Currently, when a node receives a block in future according to its local wall clock, it will mark the block as invalid and ban the peer. If the header's timestamp is more than 15 seconds ahead of our current time. In that case, the header may become valid in the future, and we don't want to disconnect a peer merely for serving us one too-far-ahead block header, to prevent an …

Workarounds forbid request genesis through network request forbid requesting duplicate data through network request

The calculation of program load cycles may be missed when executing in resume mode. Since the script execution order is now determined, this issue does not cause network splitting.

fn HeaderChecker#check_valid skipped main chain checking after this PR: https://github.com/nervosnetwork/ckb/pull/1646/files#diff-c4e017b67c1b3005ca0c446a9b0879571aa36a858b1f7ddd1b9328a884e3214bR171-R176 It will cause network forking if one transaction is using a forked block header which is not exists in local node's storage.

When a transaction contains a dep group with many cells, the resources required to process it are not linear to the transaction size nor spent script cycles.

https://github.com/nervosnetwork/ckb/blob/v0.101.2/script/src/verify.rs#L871-L879 TypeIdSystemScript resume handle is not correct when max_cycles is not enough, ScriptError::ExceededMaximumCycles will be raised directly ranther than suspend as expect, and also because script_group execution order is random, so this will happen randomly.

A remote attacker could exploit this vulnerability to exhaust ckb process memory of an affected node.

An issue was discovered in the ckb crate before 0.40.0 for Rust. A get_block_template RPC call may fail in situations where it is supposed to select a Nervos CKB blockchain transaction with a higher fee rate than another transaction.

An issue was discovered in the ckb crate before 0.40.0 for Rust. Attackers can cause a denial of service (Nervos CKB blockchain node crash) via a dead call that is used as a DepGroup.

An issue was discovered in the ckb crate before 0.40.0 for Rust. Remote attackers may be able to conduct a 51% attack against the Nervos CKB blockchain by triggering an inability to allocate memory for the misbehavior HashMap.

In the ckb sync protocol, SyncState maintains a HashMap called 'misbehavior' that keeps a score of a peer's violations of the protocol. This HashMap is keyed to PeerIndex (an alias for SessionId), and entries are never removed from it. SessionId is an integer that increases monotonically with every new connection. A remote attacker can manipulate this HashMap to grow forever, resulting in degraded performance and ultimately a panic on allocation …

It's easy to create a malign transaction which uses the dead cell as the DepGroup in the DepCells. The transaction can crash all the receiving nodes.

The RPC get_block_template fails when a cell has been used as a cell dep and an input in the different transactions. Say cell C is used as a dep group in the transaction A, and is destroyed in the transaction B. The node adds transaction A first, then B into the transaction pool. They are both valid. But when generating the block template, if the fee rate of B is …