linux-kernel - Re: [PATCH] kobject_uevent: Fix OOB access within zap_modalias

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: <tencent_6866D69439F77A09338872DC0398A84CB908@qq.com>
Date: Sun, 30 Jun 2024 23:08:17 +0800
From: Zhou congjie <zcjie0802@...com>
To: Zijun Hu <quic_zijuhu@...cinc.com>, gregkh@...uxfoundation.org, 
    rafael@...nel.org, akpm@...ux-foundation.org, dmitry.torokhov@...il.com
cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] kobject_uevent: Fix OOB access within
 zap_modalias_env()

On Fri, 24 May 2024, Zijun Hu wrote:

> Subject: [PATCH] kobject_uevent: Fix OOB access within zap_modalias_env()
> zap_modalias_env() wrongly calculates size of memory block
> to move, so maybe cause OOB memory access issue, fixed by
> correcting size to memmove.
> 
> Fixes: 9b3fa47d4a76 ("kobject: fix suppressing modalias in uevents delivered over netlink")
> Cc: stable@...r.kernel.org
> Signed-off-by: Zijun Hu <quic_zijuhu@...cinc.com>
> ---
>  lib/kobject_uevent.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> index 03b427e2707e..f153b4f9d4d9 100644
> --- a/lib/kobject_uevent.c
> +++ b/lib/kobject_uevent.c
> @@ -434,7 +434,7 @@ static void zap_modalias_env(struct kobj_uevent_env *env)
>  
>  		if (i != env->envp_idx - 1) {
>  			memmove(env->envp[i], env->envp[i + 1],
> -				env->buflen - len);
> +				env->buf + env->buflen - env->envp[i + 1]);
>  
>  			for (j = i; j < env->envp_idx - 1; j++)
>  				env->envp[j] = env->envp[j + 1] - len;
> 

I notice it too.

In the debug, I find that length of "env->buflen - len" is definitely 
larger than  "env->buf + env->buflen - env->envp[i+1". So memmove() just 
copy some extra '\0', and the problem will not happen when the length of 
env variables is much smaller than 2048. That is why the problem is 
difficult to be observed.

But when the length of env variables is close to 2048 or even more than 
2048, the memmove will access the memory not belong to env->buf[2048].