netdev - Re: [PATCH net-next v2 03/15] quic: provide common utilities and data structures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c06ff3eb-f69d-4bd8-b81a-a28b8b69ba52@redhat.com>
Date: Thu, 21 Aug 2025 14:58:36 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Xin Long <lucien.xin@...il.com>, network dev <netdev@...r.kernel.org>
Cc: davem@...emloft.net, kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>,
 Simon Horman <horms@...nel.org>, Stefan Metzmacher <metze@...ba.org>,
 Moritz Buhl <mbuhl@...nbsd.org>, Tyler Fanelli <tfanelli@...hat.com>,
 Pengtao He <hepengtao@...omi.com>, linux-cifs@...r.kernel.org,
 Steve French <smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>,
 Paulo Alcantara <pc@...guebit.com>, Tom Talpey <tom@...pey.com>,
 kernel-tls-handshake@...ts.linux.dev, Chuck Lever <chuck.lever@...cle.com>,
 Jeff Layton <jlayton@...nel.org>, Benjamin Coddington <bcodding@...hat.com>,
 Steve Dickson <steved@...hat.com>, Hannes Reinecke <hare@...e.de>,
 Alexander Aring <aahringo@...hat.com>, David Howells <dhowells@...hat.com>,
 Cong Wang <xiyou.wangcong@...il.com>, "D . Wythe"
 <alibuda@...ux.alibaba.com>, Jason Baron <jbaron@...mai.com>,
 illiliti <illiliti@...tonmail.com>, Sabrina Dubroca <sd@...asysnail.net>,
 Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
 Daniel Stenberg <daniel@...x.se>,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v2 03/15] quic: provide common utilities and data
 structures

On 8/18/25 4:04 PM, Xin Long wrote:
[...]
> +void quic_hash_tables_destroy(void)
> +{
> +	struct quic_hash_table *ht;
> +	int table;
> +
> +	for (table = 0; table < QUIC_HT_MAX_TABLES; table++) {
> +		ht = &quic_hash_tables[table];
> +		ht->size = QUIC_HT_SIZE;

Why?

> +		kfree(ht->hash);
> +	}
> +}
> +
> +int quic_hash_tables_init(void)
> +{
> +	struct quic_hash_head *head;
> +	struct quic_hash_table *ht;
> +	int table, i;
> +
> +	for (table = 0; table < QUIC_HT_MAX_TABLES; table++) {
> +		ht = &quic_hash_tables[table];
> +		ht->size = QUIC_HT_SIZE;

AFAICS the hash table size is always QUIC_HT_SIZE, which feels like too
small for connection and possibly quick sockets.

Do yoi need to differentiate the size among the different hash types?

> +		head = kmalloc_array(ht->size, sizeof(*head), GFP_KERNEL);

If so, possibly you should resort to kvmalloc_array here.

> +		if (!head) {
> +			quic_hash_tables_destroy();
> +			return -ENOMEM;
> +		}
> +		for (i = 0; i < ht->size; i++) {
> +			INIT_HLIST_HEAD(&head[i].head);
> +			if (table == QUIC_HT_UDP_SOCK) {
> +				mutex_init(&head[i].m_lock);
> +				continue;
> +			}
> +			spin_lock_init(&head[i].s_lock);

Doh, I missed the union mutex/spinlock. IMHO it would be cleaner to use
separate hash types.

[...]
> +/* Parse a comma-separated string into a 'quic_data' list format.
> + *
> + * Each comma-separated token is turned into a length-prefixed element. The
> + * first byte of each element stores the length (minus one). Elements are
> + * stored in 'to->data', and 'to->len' is updated.
> + */
> +void quic_data_from_string(struct quic_data *to, u8 *from, u32 len)
> +{
> +	struct quic_data d;
> +	u8 *p = to->data;
> +
> +	to->len = 0;
> +	while (len) {
> +		d.data = p++;
> +		d.len  = 1;
> +		while (len && *from == ' ') {
> +			from++;
> +			len--;
> +		}
> +		while (len) {
> +			if (*from == ',') {
> +				from++;
> +				len--;
> +				break;
> +			}
> +			*p++ = *from++;
> +			len--;
> +			d.len++;
> +		}
> +		*d.data = (u8)(d.len - 1);
> +		to->len += d.len;
> +	}

The above does not perform any bound checking vs the destination buffer,
it feels fragile.

/P