linux-kernel - Re: [PATCH ghak124 v3fix] audit: add gfp parameter to audit_log

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]

Message-ID: <CAGdUbJEwoxEFJZDUjF7ZwKurKNibPW86=s3yFSA6BBt-YsC=Nw@mail.gmail.com>
Date:   Fri, 3 Jul 2020 14:40:57 +0200
From:   Jones Desougi <jones.desougi+netfilter@...il.com>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        netfilter-devel@...r.kernel.org, Paul Moore <paul@...l-moore.com>,
        sgrubb@...hat.com, omosnace@...hat.com,
        Florian Westphal <fw@...len.de>, twoerner@...hat.com,
        eparis@...isplace.org, tgraf@...radead.org,
        dan.carpenter@...cle.com
Subject: Re: [PATCH ghak124 v3fix] audit: add gfp parameter to audit_log_nfcfg

Doesn't seem entirely consistent now either though. Two cases below.

   /Jones

On Sun, Jun 28, 2020 at 5:27 AM Richard Guy Briggs <rgb@...hat.com> wrote:
>
> Fixed an inconsistent use of GFP flags in nft_obj_notify() that used
> GFP_KERNEL when a GFP flag was passed in to that function.  Given this
> allocated memory was then used in audit_log_nfcfg() it led to an audit
> of all other GFP allocations in net/netfilter/nf_tables_api.c and a
> modification of audit_log_nfcfg() to accept a GFP parameter.
>
> Reported-by: Dan Carptenter <dan.carpenter@...cle.com>
> Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
> ---
> Passes audit-testsuite.
>
>  include/linux/audit.h           |  8 ++++----
>  kernel/auditsc.c                |  4 ++--
>  net/bridge/netfilter/ebtables.c |  6 +++---
>  net/netfilter/nf_tables_api.c   | 33 +++++++++++++++++++++------------
>  net/netfilter/x_tables.c        |  5 +++--
>  5 files changed, 33 insertions(+), 23 deletions(-)
>
...
> diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> index 164700273947..f7ff91479647 100644
> --- a/net/netfilter/nf_tables_api.c
> +++ b/net/netfilter/nf_tables_api.c
...
> @@ -6071,13 +6077,14 @@ static int nf_tables_getobj(struct net *net, struct sock *nlsk,
>                 reset = true;
>
>         if (reset) {
> -               char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0",
> +               char *buf = kasprintf(GFP_ATOMIC, "%s:%llu;?:0",
>                                       table->name, table->handle);
>
>                 audit_log_nfcfg(buf,
>                                 family,
>                                 obj->handle,
> -                               AUDIT_NFT_OP_OBJ_RESET);
> +                               AUDIT_NFT_OP_OBJ_RESET,
> +                               GFP_KERNEL);
>                 kfree(buf);
>         }
>

Replaces one GFP_KERNEL (with GFP_ATOMIC) but also adds a new one in
the following statement.
Is that intentional?

> @@ -6156,7 +6163,7 @@ void nft_obj_notify(struct net *net, const struct nft_table *table,
>  {
>         struct sk_buff *skb;
>         int err;
> -       char *buf = kasprintf(GFP_KERNEL, "%s:%llu;?:0",
> +       char *buf = kasprintf(gfp, "%s:%llu;?:0",
>                               table->name, table->handle);
>
>         audit_log_nfcfg(buf,
> @@ -6164,7 +6171,8 @@ void nft_obj_notify(struct net *net, const struct nft_table *table,
>                         obj->handle,
>                         event == NFT_MSG_NEWOBJ ?
>                                 AUDIT_NFT_OP_OBJ_REGISTER :
> -                               AUDIT_NFT_OP_OBJ_UNREGISTER);
> +                               AUDIT_NFT_OP_OBJ_UNREGISTER,
> +                       GFP_KERNEL);
>         kfree(buf);
>
>         if (!report &&

It would seem these two hunks form a similar discrepancy.

...

> --
> 1.8.3.1
>