Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1077917yba; Thu, 18 Apr 2019 14:54:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqyvVLPfXpAecPm0vxirbycm7O73po3iH0BmyypvgeffW1BfPax0TRfmp53Zvo00CF8BpbU2 X-Received: by 2002:a63:3284:: with SMTP id y126mr271983pgy.424.1555624491498; Thu, 18 Apr 2019 14:54:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555624491; cv=none; d=google.com; s=arc-20160816; b=SvoTRtRvNB1oDdYpBqm0dSCfrJnE161dvv7ray70kQVrRlUYcnppQxTpCCeVT+yLzj d8gfOr6UmYaCn4hh/ct8cA/+HoxRUPRcFxBNOcNf+dmY3r2q2zYh5KD9DIi/UR/Coie0 XKr24uniu+VeUDcNanBn8hOVxQT5w/Fn7cZUi95GGmGojJ9upVR/yBmjDIOEW89D2XXc 8AFP54Ok0oclEcUCzAXYwb2KRUdIMXly0jtJGHBwlX9L2R+l+/BnCg1Sa9Hrc3cmZVBZ cC4WcOkuygNJykYRDyX5fZ5+4ZGt6wJ6j4sS2gqnFsOurzgHbkOFUZaQWvkFvLk6PgzB CGHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=UnclNOyKgaVdgRUC7bKMlUdq3Z/8THTWqN3fdo44i+I=; b=hf//TzgWiO5LzLn1LInJ9UBT9FCg1OhHs+QDSfHQY6aOtLae7LeaCNtuFQxmlt0/ZZ 7Nm2o6+sFsGE2KTVBahFF/3DTjUfgwJvafnKatXVqh2IRrFqX4aZyeGQ2STZRXI3KyA3 SvvP4PsTNIXglwELX6k0gUqk+xUBD3eU9NjHBYlx8FG8kwUSgpnue/P/CmAePpVFdK5h rxNRTC2JzllmlVrqLBE2SLPVO6AMVPc6/xhLQDv8tkHuAesCToCAAS39GxyQXSKZWKpz XP9+jWNrgSWWSZKfiIZCnSWavTCJcZ4HBZ45SMlAAvJrUM8W4kY3KfdSBa8xmyY5hbmP kO/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=AMPNdNyz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y14si3051833pll.379.2019.04.18.14.54.36; Thu, 18 Apr 2019 14:54:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=AMPNdNyz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726341AbfDRVwU (ORCPT + 99 others); Thu, 18 Apr 2019 17:52:20 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:34874 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725875AbfDRVwU (ORCPT ); Thu, 18 Apr 2019 17:52:20 -0400 Received: by mail-lf1-f65.google.com with SMTP id j20so2711193lfh.2 for ; Thu, 18 Apr 2019 14:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UnclNOyKgaVdgRUC7bKMlUdq3Z/8THTWqN3fdo44i+I=; b=AMPNdNyzg0dcm4+VZaGNqKgWO1HB1nyOCsfpDKD81IUY9sxJJuoGUUYryM1PvH7pHc oDJrRv9pimFZR2H9RxXV4+gdKmNwao1L4GvKpATL9Paa6Ocap+a5zndCKsBoc64yvmSp DEBDDQKri44DqHqKV1iLj3IxBCbnN8x37UtZf3T6jx+CljBUjUjIBsxPY0TFyngKipL6 eWQ0OhiF2C98QAt/YSzRK5oggGrqIVRJXBLcEDshaWeh+yZXJm7IBBtzvLJG/B7ovjeY oCfS6LLdzPWRBpyVXZtDOqL7Z/OmOWEh97kzR0JWcPrwlK007QI6+dVIAzNNt++aSdhU GZ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UnclNOyKgaVdgRUC7bKMlUdq3Z/8THTWqN3fdo44i+I=; b=hZlfUeyq+1DYrhNYeDseZZ3mCUUpRk9BqS8OKVYyXQInOsFvd/Iw6nAIjvwHPp00vS u457VAVwr52yi+T2msdyeDUrAHyhjhGVTyZzauSgRu0SWSOxw5ePyr5gjmnv4YGn9xmz xYJtSxsa1d2E5svUMsIsNSqiopgZOxpiaeQhV99X1winY/8TEwTM68bDWyuOhXtCJBS9 JyExmpeqTmyyEAGUkfEDBQTmNTjmPpdJ84ZUjoyn79UAkgCW4Xi01DX3C3XmdQaPMeKN G3fu9GWlP4B++xku3q7FyLp0ctB5/HbGNfsXvOn7gUBLj/sWdPTtaMQu5NvIWI5ZBDYb W3pw== X-Gm-Message-State: APjAAAUESuzOEGDTzrmIxtM2oMBUWKPNkW/JOfNdtjo33mCC1RIQgmEk ABsZUmAUL0xk640KSekVcwFK15sVZF/tIBkOprxC X-Received: by 2002:a19:760f:: with SMTP id c15mr205457lff.105.1555624337550; Thu, 18 Apr 2019 14:52:17 -0700 (PDT) MIME-Version: 1.0 References: <1555609155-11934-1-git-send-email-wang6495@umn.edu> In-Reply-To: <1555609155-11934-1-git-send-email-wang6495@umn.edu> From: Paul Moore Date: Thu, 18 Apr 2019 17:52:06 -0400 Message-ID: Subject: Re: [PATCH] audit: fix a memory leak bug To: Wenwen Wang Cc: Eric Paris , "moderated list:AUDIT SUBSYSTEM" , open list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 18, 2019 at 1:39 PM Wenwen Wang wrote: > In audit_rule_change(), audit_data_to_entry() is firstly invoked to > translate the payload data to the kernel's rule representation. In > audit_data_to_entry(), depending on the audit field type, an audit tree may > be created in audit_make_tree(), which eventually invokes kmalloc() to > allocate the tree. Since this tree is a temporary tree, it will be then > freed in the following execution, e.g., audit_add_rule() if the message > type is AUDIT_ADD_RULE or audit_del_rule() if the message type is > AUDIT_DEL_RULE. However, if the message type is neither AUDIT_ADD_RULE nor > AUDIT_DEL_RULE, i.e., the default case of the switch statement, this > temporary tree is not freed. > > To fix this issue, free the allocated tree in the default case. > > Signed-off-by: Wenwen Wang > --- > kernel/auditfilter.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c > index 63f8b3f..70a34db 100644 > --- a/kernel/auditfilter.c > +++ b/kernel/auditfilter.c > @@ -1128,6 +1128,8 @@ int audit_rule_change(int type, int seq, void *data, size_t datasz) > audit_log_rule_change("remove_rule", &entry->rule, !err); > break; > default: > + if (entry->rule.tree) > + audit_put_tree(entry->rule.tree); > err = -EINVAL; > WARN_ON(1); > } Since there are only two "types" (_ADD_RULE and _DEL_RULE) and the allocation is only three lines (audit_data_to_entry() + two lines for error handling), maybe it makes more sense to duplicate the audit_data_to_entry() call into the individual case statements so we are only doing the allocations when we have a valid "type"? -- paul moore www.paul-moore.com