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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 10 Jun 2020 15:10:17 -0400
From:   Stephen Smalley <stephen.smalley.work@...il.com>
To:     trix@...hat.com
Cc:     Paul Moore <paul@...l-moore.com>,
        Eric Paris <eparis@...isplace.org>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        Jeffrey Vander Stoep <jeffv@...gle.com>, rgb@...hat.com,
        SElinux list <selinux@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] selinux: fix double free

On Wed, Jun 10, 2020 at 2:10 PM <trix@...hat.com> wrote:
>
> From: Tom Rix <trix@...hat.com>
>
> Clang's static analysis tool reports these double free memory errors.
>
> security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc]
>                         kfree(bnames[i]);
>                         ^~~~~~~~~~~~~~~~
> security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc]
>         kfree(bvalues);
>         ^~~~~~~~~~~~~~
>
> So improve the security_get_bools error handling by freeing these variables
> and setting their return pointers to NULL and the return len to 0
>
> Signed-off-by: Tom Rix <trix@...hat.com>
> ---
>  security/selinux/ss/services.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 313919bd42f8..2dffae1feaff 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -2888,8 +2888,12 @@ int security_get_bools(struct selinux_state *state,
>         if (*names) {
>                 for (i = 0; i < *len; i++)
>                         kfree((*names)[i]);
> +               kfree(names);

kfree(*names)?

>         }
>         kfree(*values);
> +       *len = 0;
> +       *names = NULL;
> +       *values = NULL;
>         goto out;
>  }

Wondering if the caller handling ought to be changed too even though
this should avoid the problem.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ