public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Paul Moore <paul@paul-moore.com>, wang.yi59@zte.com.cn
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org,
	jiang.biao2@zte.com.cn, zhong.weidong@zte.com.cn
Subject: Re: [PATCH] audit: fix potential null dereference 'context->module.name'
Date: Tue, 24 Jul 2018 18:38:54 -0400	[thread overview]
Message-ID: <89963f4c8c4f89bc766ffc0b58fe8e24942c3793.camel@redhat.com> (raw)
In-Reply-To: <CAHC9VhQy6Rakx6WZ236R+PjwtaZ2Sq9SuoGMC8iejOmhRbCM_w@mail.gmail.com>

On Tue, 2018-07-24 at 15:55 -0400, Paul Moore wrote:
> On Tue, Jul 24, 2018 at 7:39 AM Eric Paris <eparis@redhat.com> wrote:
> > Would it make more sense to actually check for failure on
> > allocation
> > rather than try to remember to deal with it later? How about we
> > just
> > have audit_log_kern_module return an error and fail if we are OOM?
> 
> Generally I agree, checking on allocation is the right thing to do.
> However, in this particular case the error recovery for a failed
> allocation would likely ignore the record entirely, and I think a
> module load record with a "(null)" module name is still better than
> no
> module load record at all ... and yes, I understand that if the
> module
> name allocation fails there is a good chance other allocations will
> fail and we might not emit the record, but I'll take my chances that
> the load is transient and the system is able to recover in a timely
> manner.

On the load_module() code path passing the error up the stack would
cause the module to not be loaded, instead of being loaded with loss of
name information. I'd rather have the module not loaded and a
name=(null) record than it BE loaded and get name=(null)

You've sold me on why Yi Wang's patch is good, but not on why we
wouldn't propagate the error up the stack on load/delete. (even if we
may choose to delete the module on OOM)

-Eric

> > (also this seems like a good place to use kstrdup, instead of
> > kmalloc+strcpy)
> 
> Yes, I agree.  Yi Wang, could you submit a v2 of this patch using
> kstrdup()?
> 
> > On Tue, 2018-07-24 at 13:57 +0800, Yi Wang wrote:
> > > The variable 'context->module.name' may be null pointer when
> > > kmalloc return null, so it's better to check it before using
> > > to avoid null dereference.
> > > 
> > > Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
> > > Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
> > > ---
> > >  kernel/auditsc.c | 11 ++++++++---
> > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index e80459f..4830b83 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -1272,8 +1272,12 @@ static void show_special(struct
> > > audit_context
> > > *context, int *call_panic)
> > >               break;
> > >       case AUDIT_KERN_MODULE:
> > >               audit_log_format(ab, "name=");
> > > -             audit_log_untrustedstring(ab, context-
> > > >module.name);
> > > -             kfree(context->module.name);
> > > +             if (context->module.name) {
> > > +                     audit_log_untrustedstring(ab, context-
> > > > module.name);
> > > 
> > > +                     kfree(context->module.name);
> > > +             } else
> > > +                     audit_log_format(ab, "(null)");
> > > +
> > >               break;
> > >       }
> > >       audit_log_end(ab);
> > > @@ -2409,7 +2413,8 @@ void __audit_log_kern_module(char *name)
> > >       struct audit_context *context = current->audit_context;
> > > 
> > >       context->module.name = kmalloc(strlen(name) + 1,
> > > GFP_KERNEL);
> > > -     strcpy(context->module.name, name);
> > > +     if (context->module.name)
> > > +             strcpy(context->module.name, name);
> > >       context->type = AUDIT_KERN_MODULE;
> > >  }
> > > 
> 
> 
> 

  reply	other threads:[~2018-07-24 22:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-24  5:57 [PATCH] audit: fix potential null dereference 'context->module.name' Yi Wang
2018-07-24 11:39 ` Eric Paris
2018-07-24 19:55   ` Paul Moore
2018-07-24 22:38     ` Eric Paris [this message]
2018-07-24 23:38       ` Paul Moore
2018-07-25  0:55         ` wang.yi59

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=89963f4c8c4f89bc766ffc0b58fe8e24942c3793.camel@redhat.com \
    --to=eparis@redhat.com \
    --cc=jiang.biao2@zte.com.cn \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=wang.yi59@zte.com.cn \
    --cc=zhong.weidong@zte.com.cn \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox