Summary
A malicious remote server can send a tampered QUIC ACK frame, causing a Firefox instance to attempt a memory allocation of a size chosen by the server. This can lead to crashes either from genuine memory exhaustion or from failed allocation attempts.
Details
When decoding a QUIC ACK frame, Neqo will first read the ACK range count (nr) and then allocate a Vec with a capacity of the count (arr). It does not enforce an upper bound on the count (nr). Thus an attacker can choose an arbitrarily large ACK range count (nr) and thus cause Neqo to attempt an effectively infinite memory allocation.
|
FRAME_TYPE_ACK | FRAME_TYPE_ACK_ECN => { |
|
let la = dv(dec)?; |
|
let ad = dv(dec)?; |
|
let nr = dv(dec)?; |
|
let fa = dv(dec)?; |
|
let mut arr: Vec<AckRange> = Vec::with_capacity(nr as usize); |
Summary
A malicious remote server can send a tampered QUIC ACK frame, causing a Firefox instance to attempt a memory allocation of a size chosen by the server. This can lead to crashes either from genuine memory exhaustion or from failed allocation attempts.
Details
When decoding a QUIC ACK frame, Neqo will first read the ACK range count (
nr) and then allocate aVecwith a capacity of the count (arr). It does not enforce an upper bound on the count (nr). Thus an attacker can choose an arbitrarily large ACK range count (nr) and thus cause Neqo to attempt an effectively infinite memory allocation.neqo/neqo-transport/src/frame.rs
Lines 410 to 415 in 4de3279