Re: [PATCH net-next v6 03/16] quic: provide common utilities and data structures

Paolo Abeni <[email protected]>
Newsgroups dev.linux.lists.kernel-tls-handshake,dev.linux.lists.quic,org.kernel.vger.linux-cifs,org.kernel.vger.netdev
Message-ID <[email protected]>
On 1/5/26 3:04 PM, Xin Long wrote:
> +/* Check whether 'd2' is equal to any element inside the list 'd1'.
> + *
> + * 'd1' is assumed to be a sequence of length-prefixed elements. Each element
> + * is compared to 'd2' using 'quic_data_cmp()'.
> + *
> + * Returns 1 if a match is found, 0 otherwise.
> + */
> +int quic_data_has(struct quic_data *d1, struct quic_data *d2)
> +{
> +	struct quic_data d;
> +	u64 length;
> +	u32 len;
> +	u8 *p;
> +
> +	for (p = d1->data, len = d1->len; len; len -= length, p += length) {
> +		quic_get_int(&p, &len, &length, 1);
> +		quic_data(&d, p, length);
> +		if (!quic_data_cmp(&d, d2))
> +			return 1;

AI review found something likely relevant here:

"""
Can this cause an integer underflow?  When 'length' (read from the data)
is greater than the remaining 'len', the subtraction 'len -= length' will
wrap the u32 to a very large value, causing out-of-bounds memory access.

Compare with quic_data_to_string() which validates: 'len < length'.

The same issue exists in quic_data_match() below.
"""

/P
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.