Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1540613

Re: [PATCH v2] audit: use proper refcount locking on audit_sock

Show all headers | View raw

On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> Resetting audit_sock appears to be racy.
>
> audit_sock was being copied and dereferenced without using a refcount on
> the source sock.
>
> Bump the refcount on the underlying sock when we store a refrence in
> audit_sock and release it when we reset audit_sock.  audit_sock
> modification needs the audit_cmd_mutex.
>
> See: https://lkml.org/lkml/2016/11/26/232
>
> Thanks to Eric Dumazet <edumazet@google.com> and Cong Wang
> <xiyou.wangcong@gmail.com> on ideas how to fix it.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> There has been a lot of change in the audit code that is about to go
> upstream to address audit queue issues.  This patch is based on the
> source tree: git://git.infradead.org/users/pcmoore/audit#next
> ---
>  kernel/audit.c |   34 ++++++++++++++++++++++++++++------
>  1 files changed, 28 insertions(+), 6 deletions(-)

My previous question about testing still stands, but I took a closer
look and have some additional comments, see below ...

> diff --git a/kernel/audit.c b/kernel/audit.c
> index f20eee0..439f7f3 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -452,7 +452,9 @@ static void auditd_reset(void)
>         struct sk_buff *skb;
>
>         /* break the connection */
> +       sock_put(audit_sock);
>         audit_pid = 0;
> +       audit_nlk_portid = 0;
>         audit_sock = NULL;
>
>         /* flush all of the retry queue to the hold queue */
> @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff *skb)
>         if (rc >= 0) {
>                 consume_skb(skb);
>                 rc = 0;
> +       } else {
> +               if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {

I dislike the way you wrote this because instead of simply looking at
this to see if it correct I need to sort out all the bits and find out
if there are other error codes that could run afoul of this check ...
make it simple, e.g. (rc == -ENOMEM || rc == -EPERM || ...).
Actually, since EPERM is 1, -EPERM (-1 in two's compliment is
0xffffffff) is going to cause this to be true for pretty much any
value of rc, yes?

> +                       mutex_lock(&audit_cmd_mutex);
> +                       auditd_reset();
> +                       mutex_unlock(&audit_cmd_mutex);
> +               }

The code in audit#next handles netlink_unicast() errors in
kauditd_thread() and you are adding error handling code here in
kauditd_send_unicast_skb() ... that's messy.  I don't care too much
where the auditd_reset() call is made, but let's only do it in one
function; FWIW, I originally put the error handling code in
kauditd_thread() because there was other error handling code that
needed to done in that scope so it resulted in cleaner code.

Related, I see you are now considering ENOMEM to be a fatal condition,
that differs from the AUDITD_BAD macro in kauditd_thread(); this
difference needs to be reconciled.

Finally, you should update the comment header block for auditd_reset()
that it needs to be called with the audit_cmd_mutex held.

> @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
>                                 return -EACCES;
>                         }
>                         if (audit_pid && new_pid &&
> -                           audit_replace(requesting_pid) != -ECONNREFUSED) {
> +                           (audit_replace(requesting_pid) & (-ECONNREFUSED|-EPERM|-ENOMEM))) {

Do we simply want to treat any error here as fatal, and not just
ECONN/EPERM/ENOMEM?  If not, let's come up with a single macro to
handle the fatal netlink_unicast() return codes so we have some chance
to keep things consistent in the future.

-- 
paul moore
www.paul-moore.com

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH v2] audit: use proper refcount locking on audit_sock Richard Guy Briggs <rgb@redhat.com> - 2016-12-12 11:10 +0100
  Re: [PATCH v2] audit: use proper refcount locking on audit_sock Paul Moore <paul@paul-moore.com> - 2016-12-12 18:20 +0100
    Re: [PATCH v2] audit: use proper refcount locking on audit_sock Richard Guy Briggs <rgb@redhat.com> - 2016-12-13 06:00 +0100
  Re: [PATCH v2] audit: use proper refcount locking on audit_sock Paul Moore <paul@paul-moore.com> - 2016-12-12 21:20 +0100
    Re: [PATCH v2] audit: use proper refcount locking on audit_sock Richard Guy Briggs <rgb@redhat.com> - 2016-12-13 06:20 +0100
      Re: [PATCH v2] audit: use proper refcount locking on audit_sock Richard Guy Briggs <rgb@redhat.com> - 2016-12-13 16:10 +0100
  Re: [PATCH v2] audit: use proper refcount locking on audit_sock Cong Wang <xiyou.wangcong@gmail.com> - 2016-12-13 01:00 +0100
    Re: [PATCH v2] audit: use proper refcount locking on audit_sock Richard Guy Briggs <rgb@redhat.com> - 2016-12-13 16:00 +0100

csiph-web