Received: by 2002:a17:90a:c8b:0:0:0:0 with SMTP id v11csp2301412pja; Fri, 19 Apr 2019 11:34:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqyde1CrUOE31ww8NL7Q6WLgJddgGwdcTQNgH0VW1HrPP7u6huj8WP7gxRszS0NXXmitHjD6 X-Received: by 2002:a17:902:43a4:: with SMTP id j33mr5313922pld.307.1555698892092; Fri, 19 Apr 2019 11:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555698892; cv=none; d=google.com; s=arc-20160816; b=KgwH5ZxQyHYTOATqH2R2e3mFZghIh7dQzhoc/HWZjjURkaNc+GyDs9u3oc5X8fYg4C /N5vNVfHNOPC39mGeMv9Bi5tAUiRKSB5pVU9AboNfEKinH8/i74b5IRmIR8QqGmqHom/ JbEouWljiaLAZLOhT39H+lrLvr7W1klwq2ynMpGCsRyFf0SMM0fCl6VZU6lHLkT/kGZ3 T78fH2hwZd/r1sbEG2hPNSlHxI+BqIxgeGE7oEu84WmVHjWSCb8kwHNXd7s4fa0FWYkM W/3nBu3wId7nbXyjgmQt/qrTGHYX1S4fJezo77f42mlHTRj3tw1gT5/fr7aB2vfonQMk ytwA== 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=AYZJoJS+iuii1jRvu8wC9cMnC3j/vmSGalc5wVfBBkg=; b=cZRnBblapJ24n/JWrXOWGJKR5kvuCp87Lk2I4F+19F8fiGtQusoJeQUqPeeOdP3XKo ZOnjpF1s2qufhhr+wbLQoH8Vx1m4QQOTLx1/o4dAOzH5qsu1qHQpEJM6rZbaErbpm9Uw bWrDK+eO8GOuPNvumkjFpj1hExLPhqOR9SZ4H41JbBoDqYJN8B4GSDs369boubDVEG8V COMW4asAkG0WifzVLrSi1ZYueF8omCLguWxwFnTJC8yLBIjnp1/phEZsjnRWByDX1pAZ 38kJZw4LpWQiczhtbulQAJ2Sv9ucjrCCNL/PMbg2cjvOnFz5DQHMt7uGe0RYTDOg/jDu y65Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@umn.edu header.s=20160920 header.b=AQhooiIg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umn.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j73si5245527pge.370.2019.04.19.11.34.36; Fri, 19 Apr 2019 11:34:52 -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=@umn.edu header.s=20160920 header.b=AQhooiIg; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=umn.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727962AbfDSSdI (ORCPT + 99 others); Fri, 19 Apr 2019 14:33:08 -0400 Received: from mta-p4.oit.umn.edu ([134.84.196.204]:49622 "EHLO mta-p4.oit.umn.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726498AbfDSSdH (ORCPT ); Fri, 19 Apr 2019 14:33:07 -0400 Received: from localhost (localhost [127.0.0.1]) by mta-p4.oit.umn.edu (Postfix) with ESMTP id 7EB369D2 for ; Fri, 19 Apr 2019 14:53:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=umn.edu; h= content-type:content-type:subject:subject:message-id:date:date :from:from:in-reply-to:references:mime-version:received:received :received; s=20160920; t=1555685638; x=1557500039; bh=31oGmTi/8q 5ICv6csH/a0i3xHhtcR0M4GwKNTKNZs8o=; b=AQhooiIgZD2YL20ymMhnu4gseZ nwzdh+MZgsDfA9N59TEvZEspOSwvy6h+cYNLVXyqYuGeBQlxeHREMmZkbwWcdny/ Vfdbd9d1WH2HWwQdOXI+z8zH+7a7YKP+4YoQEIqIvvo+aF6MMZop9co+8Ajmc61M ASb8DhBdct7FgNwRXSpd98qjYWlGQHvMspqLlUBrNpU7jP+Qz5UEjonMH5RD2/q0 RK8LSvwqFpnUJ4QXIkD37oxE31Mpe2Mp2arvmihAEfXBSAKZEPt8HQwly60gyUB8 zypQ+NNnVfrZ6i8X/D3EUZnc4Ndn2YdTVf1cm+QLXam6XQOFfKq/sn8LrZwg== X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p4.oit.umn.edu ([127.0.0.1]) by localhost (mta-p4.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeA9b8UNA3WR for ; Fri, 19 Apr 2019 09:53:58 -0500 (CDT) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: wang6495) by mta-p4.oit.umn.edu (Postfix) with ESMTPSA id 5B133985 for ; Fri, 19 Apr 2019 09:53:58 -0500 (CDT) Received: by mail-it1-f182.google.com with SMTP id 139so8565361ita.4 for ; Fri, 19 Apr 2019 07:53:58 -0700 (PDT) X-Gm-Message-State: APjAAAXfSu8HoVOTVEm8t/tEKOs+MiJFBf3gdKergUyq/Hy6Uv4Fw0jg jzxukEFkIYXsB7fNlp1ActsIwW5LWgzUt0gd0LQ= X-Received: by 2002:a02:1006:: with SMTP id 6mr3021565jay.47.1555685638125; Fri, 19 Apr 2019 07:53:58 -0700 (PDT) MIME-Version: 1.0 References: <1555609155-11934-1-git-send-email-wang6495@umn.edu> In-Reply-To: From: Wenwen Wang Date: Fri, 19 Apr 2019 09:53:22 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] audit: fix a memory leak bug To: Paul Moore Cc: Eric Paris , "moderated list:AUDIT SUBSYSTEM" , open list , Wenwen Wang 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 4:52 PM Paul Moore wrote: > > 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"? > This sounds reasonable to me. I will rework the patch. Thanks! Wenwen