All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: quic_zijuhu <quic_zijuhu@quicinc.com>
Cc: rafael@kernel.org, akpm@linux-foundation.org,
	dmitry.torokhov@gmail.com, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] kobject_uevent: Fix OOB access within zap_modalias_env()
Date: Fri, 24 May 2024 07:21:10 +0200	[thread overview]
Message-ID: <2024052438-hesitate-chevron-dbd7@gregkh> (raw)
In-Reply-To: <74465bf5-ca18-45f8-a881-e95561c59a02@quicinc.com>

On Fri, May 24, 2024 at 01:15:01PM +0800, quic_zijuhu wrote:
> On 5/24/2024 12:33 PM, Greg KH wrote:
> > On Fri, May 24, 2024 at 12:20:03PM +0800, Zijun Hu wrote:
> >> zap_modalias_env() wrongly calculates size of memory block
> >> to move, so maybe cause OOB memory access issue, fixed by
> >> correcting size to memmove.
> > 
> > "maybe" or "does"?  That's a big difference :)
> > 
> i found this issue by reading code instead of really meeting this issue.
> this issue should be prone to happen if there are more than 1 other
> environment vars.

But does it?  Given that we have loads of memory checkers, and I haven't
ever seen any report of any overrun, it would be nice to be sure.

> do you have suggestion about term to use?

Some confirmation that this really is the case would be nice :)

> >> Fixes: 9b3fa47d4a76 ("kobject: fix suppressing modalias in uevents delivered over netlink")
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.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]);
> > 
> > How is this "more correct"?  Please explain it better, this logic is not
> > obvious at all.
> > 
> env->envp[] contains pointers to env->buf[] with length env->buflen,
> we want to delete environment variable pointed by env->envp[i] with
> length @len as shown below.
> 
> env->buf[]            |-> target block <-|
> 0-----------------------------------------env->buflen
>         ^             ^
> 	| ->  @len <- |
>   env->envp[i]   env->envp[i+1]
> 
> so move "target block" forward by @len, so size of target block is
> env->buf + env->buflen - env->envp[i+1] instead of env->buflen
> -len.
> 
> do you suggest add inline comments to explain it ?

Yes please.

thanks,

greg k-h

  reply	other threads:[~2024-05-24  5:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-24  4:20 [PATCH] kobject_uevent: Fix OOB access within zap_modalias_env() Zijun Hu
2024-05-24  4:33 ` Greg KH
2024-05-24  5:15   ` quic_zijuhu
2024-05-24  5:21     ` Greg KH [this message]
2024-05-24  5:34       ` quic_zijuhu
2024-05-24  6:56         ` Greg KH
2024-05-24  9:08           ` quic_zijuhu
2024-05-24 11:47             ` Greg KH
2024-05-24 14:46               ` quic_zijuhu
2024-06-30 15:08 ` Zhou congjie
2024-07-04 14:01   ` quic_zijuhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024052438-hesitate-chevron-dbd7@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_zijuhu@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.