netdev - Re: [PATCH net] netlink: Fix off-by-one error in netlink_proto

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: <20241028182421.6692-1-kuniyu@amazon.com>
Date: Mon, 28 Oct 2024 11:24:21 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <ruanjinjie@...wei.com>
CC: <a.kovaleva@...ro.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<horms@...nel.org>, <kuba@...nel.org>, <kuniyu@...zon.com>,
	<linux-kernel@...r.kernel.org>, <lirongqing@...du.com>,
	<netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH net] netlink: Fix off-by-one error in netlink_proto_init()

From: Jinjie Ruan <ruanjinjie@...wei.com>
Date: Mon, 28 Oct 2024 16:05:15 +0800
> In the error path of netlink_proto_init(), frees the already allocated
> bucket table for new hash tables in a loop, but the loop condition
> terminates when the index reaches zero, which fails to free the first
> bucket table at index zero.
> 
> Check for >= 0 so that nl_table[0].hash is freed as well.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Jinjie Ruan <ruanjinjie@...wei.com>
> ---
>  net/netlink/af_netlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 0a9287fadb47..9601b85dda95 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -2936,7 +2936,7 @@ static int __init netlink_proto_init(void)
>  	for (i = 0; i < MAX_LINKS; i++) {
>  		if (rhashtable_init(&nl_table[i].hash,
>  				    &netlink_rhashtable_params) < 0) {
> -			while (--i > 0)
> +			while (--i >= 0)
>  				rhashtable_destroy(&nl_table[i].hash);
>  			kfree(nl_table);
>  			goto panic;

I remember the same question was posted in the past.
https://lore.kernel.org/netdev/ZfOalln%2FmyRNOkH6@cy-server/

As Eric alreday pointed out (and as mentioned in the thread above too),
it's going to panic, and we need not clean up resources here, so let's
remove rhashtable_destroy() and kfree() instead of adjusting the loop
condition.