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@xxxxxxxxxxxxxxx
>> Signed-off-by: Zijun Hu <quic_zijuhu@xxxxxxxxxxx>
>> ---
>> 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].
>
