Re: [PATCH 3/3] audit: drop audit_cmd_lock in AUDIT_USER family ofcases

[Toshiyuki Okajima]

On Wed,  4 Dec 2013 21:45:56 -0500
Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:

> We do not need to hold the audit_cmd_mutex for this family of cases.  The
> possible exception to this is the call to audit_filter_user(), so drop the lock
> immediately after.  To help in fixing the race we are trying to avoid, make
> sure that nothing called by audit_filter_user() calls audit_log_start().  In
> particular, watch out for *_audit_rule_match().
> 
> This fix will take care of systemd and anything USING audit.  It still means
> that we could race with something configuring audit and auditd shutting down.
> 
> Signed-off-by: Richard Guy Briggs <rgb@xxxxxxxxxxxx>
> Signed-off-by: Richard Guy Briggs <rgb@xxxxxxxxxx>

When I have tested a patch with my reproducer, 
a hangup by this problem doesn't occur. 
//// reproducer ////
 # auditctl -a exit,always -S all
 # reboot
/////////////////////////

So, this fix looks good to me.

Please add:

Reported-by: toshi.okajima@xxxxxxxxxxxxxx
Tested-by: toshi.okajima@xxxxxxxxxxxxxx

Thanks.

> ---
>  kernel/audit.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 4689012..4cbc945 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -713,6 +713,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
>  				if (err)
>  					break;
>  			}
> +			mutex_unlock(&audit_cmd_mutex);
>  			audit_log_common_recv_msg(&ab, msg_type);
>  			if (msg_type != AUDIT_USER_TTY)
>  				audit_log_format(ab, " msg='%.1024s'",
> @@ -729,6 +730,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
>  			}
>  			audit_set_pid(ab, NETLINK_CB(skb).portid);
>  			audit_log_end(ab);
> +			mutex_lock(&audit_cmd_mutex);
>  		}
>  		break;
>  	case AUDIT_ADD_RULE:
> -- 
> 1.7.1
> 


-- 
Toshiyuki Okajima <toshi.okajima@xxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/