linux-kernel - Re: [net-next,v6,01/13] octeontx2-af: npc: cn20k: Index management

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: <20260129051301.376533-1-kuba@kernel.org>
Date: Wed, 28 Jan 2026 21:13:01 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: rkannoth@...vell.com
Cc: Jakub Kicinski <kuba@...nel.org>,
	edumazet@...gle.com,
	sumang@...vell.com,
	linux-kernel@...r.kernel.org,
	sbhatta@...vell.com,
	davem@...emloft.net,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	andrew+netdev@...n.ch,
	sgoutham@...vell.com
Subject: Re: [net-next,v6,01/13] octeontx2-af: npc: cn20k: Index management

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
octeontx2-af: npc: cn20k: Index management

This patch adds MCAM index management for CN20K silicon, implementing
contiguous and non-contiguous allocation schemes across the new subbank
architecture with 32 subbanks of 256 entries each.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> new file mode 100644
> index 000000000000..30cc05c64487
> --- /dev/null
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c

[ ... ]

> +static int npc_create_srch_order(int cnt)
> +{
> +	int val = 0;
> +
> +	subbank_srch_order = kcalloc(cnt, sizeof(int),
> +				     GFP_KERNEL);
> +	if (!subbank_srch_order)
> +		return -ENOMEM;
> +
> +	for (int i = 0; i < cnt; i += 2) {
> +		subbank_srch_order[i] = cnt / 2 - val - 1;
> +		subbank_srch_order[i + 1] = cnt / 2 + 1 + val;
                                   ^^^^^

When cnt is odd, the final loop iteration has i = cnt - 1, which means
subbank_srch_order[i + 1] writes to index cnt, which is out of bounds.

For example with cnt = 5, the loop iterates with i = 0, 2, 4. At i = 4,
the array access subbank_srch_order[5] overflows the allocated array of
5 elements.

While CN20K hardware typically has 32 subbanks (even), the value is read
from a hardware register at npc_priv_init() without validation beyond
checking for zero. Could this lead to memory corruption if the hardware
reports an odd subbank count?

> +		val++;
> +	}
> +
> +	subbank_srch_order[cnt - 1] = cnt / 2;
> +	return 0;
> +}

[ ... ]
-- 
pw-bot: cr