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 for Android: free password hash cracker in your pocket

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

Message-ID: <13741696-6f30-40b0-be95-2406208cbe0c@quicinc.com>
Date: Thu, 4 Jul 2024 22:01:15 +0800
From: quic_zijuhu <quic_zijuhu@...cinc.com>
To: Zhou congjie <zcjie0802@...com>
CC: <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>,
        <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
        <akpm@...ux-foundation.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH] kobject_uevent: Fix OOB access within zap_modalias_env()

On 6/30/2024 11:08 PM, Zhou congjie wrote:
> 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.
>
yes, it is a factor of why this issue is not easy 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]. 
>