linux-kernel - Re: [PATCH] kernel: auditfilter: Fix a possible null-pointer dereference in audit_watch

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] [day] [month] [year] [list]

Message-ID: <CAHC9VhQJwif4NXVydmQkTUXgM8Xnp5rG_zscXmKc5_CSYo-e5w@mail.gmail.com>
Date:   Wed, 24 Jul 2019 16:45:52 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
Cc:     Eric Paris <eparis@...hat.com>, linux-audit@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel: auditfilter: Fix a possible null-pointer
 dereference in audit_watch_path()

On Tue, Jul 23, 2019 at 8:50 AM Jia-Ju Bai <baijiaju1990@...il.com> wrote:
> In audit_find_rule(), there is an if statement on line 894 to check
> whether entry->rule.watch is NULL:
>     else if (entry->rule.watch)
>
> If entry->rule.watch is NULL, audit_compare_rule on 910 is called:
>     audit_compare_rule(&entry->rule, &e->rule))
>
> In audit_compare_rule(), a->watch is used on line 720:
>     if (strcmp(audit_watch_path(a->watch), ...)
>
> In this case, a->watch is NULL, and audit_watch_path() will use:
>     watch->path
>
> Thus, a possible null-pointer dereference may occur in this case.
>
> To fix this possible bug, an if statement is added in
> audit_compare_rule() to check a->watch before using a->watch.
>
> This bug is found by a static analysis tool STCheck written by us.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@...il.com>
> ---
>  kernel/auditfilter.c | 2 ++
>  1 file changed, 2 insertions(+)

Thank you for taking the time to analyze the kernel's audit subsystem
and send a report, but I believe this is a false positive.

The only way we can hit the AUDIT_WATCH comparison in
audit_compare_rules is if both rules are AUDIT_WATCH rules, and when
we create the audit_krule entries we ensure that the watch field is
correctly populated for AUDIT_WATCH rules, see the
audit_data_to_entry() and audit_to_watch() functions.

If you disagree with this, please let us know, but as of right now I
don't believe there is a problem here.

> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index b0126e9c0743..b0ad17b14609 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -717,6 +717,8 @@ static int audit_compare_rule(struct audit_krule *a, struct audit_krule *b)
>                                 return 1;
>                         break;
>                 case AUDIT_WATCH:
> +                       if (!a->watch)
> +                               break;
>                         if (strcmp(audit_watch_path(a->watch),
>                                    audit_watch_path(b->watch)))
>                                 return 1;
> --
> 2.17.0

-- 
paul moore
www.paul-moore.com