Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5248676ybi; Tue, 4 Jun 2019 03:49:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqx4akZGJ1ADpKk1AuXw3qs011Z9+ptql6g6DYeaGNcCUKJKC841t1uaIrYwz+IndTkhBCcv X-Received: by 2002:a63:68c5:: with SMTP id d188mr34856913pgc.429.1559645355290; Tue, 04 Jun 2019 03:49:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559645355; cv=none; d=google.com; s=arc-20160816; b=PVGY5vmyG9rD/Pkvo/NxUEqYwySYLIXzEyGOw31VkAe6PHcf1hHIK1E5FKAGxxt0kU sj8BLzwk0uNTtJ1JRuhqzZpatIUGPbt1BrmCgMXf4F9qsrzX4tBnPSLx57jPjXWcUQPa 9EWOga3ze80Poqi0lACsW9WSXILkTEg4p9GlvtcHlLwcWgVZY8FiiV9wjWj++7yy5Kh9 GrSM6oy7thiG+zNGk8FNVY9fykBsA4nliqGkBj7STUD8G+6hG0syI/ALiJD01Beowcw6 KmfWvHzpsdwm+rJLU30zoeNn+Vh/xl6pbEY3y/g+ppmqy1513pde1L0KDg2ZDDJAAY33 k0OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=cjwN7MZgQEvR6nxE1gEfYuUm8LuM+GU2Mk/z7VVWn4U=; b=EB/7pB37unHFVRh/0BBTT9u3PcGpXFok0YUqdI+JHbJWEN3+eJnmdvneVZYHHSHIN9 3d6xBiks3CRSwrjdfHvmkEL+Mzx2n3QgkV6R4UWTZ7k5+iwOFC0OH2/IdHI1eGpAhv9g NrBYP6GnLeI/TdiC1VW3e7mIAJUW8FYJwTFCRerpdNInAT+up04Y/yfUSC8G9osLA3Hr CI6xJedhfn7eFshXL2oC4ced4v+340HT46tFO79ddmqhmUEx2ZOOtiFrAO8ez4RRP6iD gWzX/nernVwf5/vcPxoOOgAF/tKSI6RfAc3aZ8NpqWUb3p5OUYh7GKtZ4+tOV/qLxATQ VCsg== ARC-Authentication-Results: i=1; mx.google.com; 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 q3si21908137pgc.116.2019.06.04.03.48.56; Tue, 04 Jun 2019 03:49:15 -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; 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 S1727590AbfFDKqK (ORCPT + 99 others); Tue, 4 Jun 2019 06:46:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:34870 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727268AbfFDKqK (ORCPT ); Tue, 4 Jun 2019 06:46:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 23DF3AFAF; Tue, 4 Jun 2019 10:46:09 +0000 (UTC) Date: Tue, 4 Jun 2019 12:46:08 +0200 (CEST) From: Miroslav Benes To: YueHaibing cc: jeyu@kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] kernel/module: Fix mem leak in module_add_modinfo_attrs In-Reply-To: <20190603144554.18168-1-yuehaibing@huawei.com> Message-ID: References: <20190530134304.4976-1-yuehaibing@huawei.com> <20190603144554.18168-1-yuehaibing@huawei.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Jun 2019, YueHaibing wrote: > In module_add_modinfo_attrs if sysfs_create_file > fails, we forget to free allocated modinfo_attrs > and roll back the sysfs files. > > Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting") > Signed-off-by: YueHaibing > --- > v3: reuse module_remove_modinfo_attrs > v2: free from '--i' instead of 'i--' > --- > kernel/module.c | 21 ++++++++++++++++----- > 1 file changed, 16 insertions(+), 5 deletions(-) I'm afraid it is not completely correct. > diff --git a/kernel/module.c b/kernel/module.c > index 80c7c09..c6b8912 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -1697,6 +1697,8 @@ static int add_usage_links(struct module *mod) > return ret; > } > > +static void module_remove_modinfo_attrs(struct module *mod, int end); > + > static int module_add_modinfo_attrs(struct module *mod) > { > struct module_attribute *attr; > @@ -1711,24 +1713,33 @@ static int module_add_modinfo_attrs(struct module *mod) > return -ENOMEM; > > temp_attr = mod->modinfo_attrs; > - for (i = 0; (attr = modinfo_attrs[i]) && !error; i++) { > + for (i = 0; (attr = modinfo_attrs[i]); i++) { > if (!attr->test || attr->test(mod)) { > memcpy(temp_attr, attr, sizeof(*temp_attr)); > sysfs_attr_init(&temp_attr->attr); > error = sysfs_create_file(&mod->mkobj.kobj, > &temp_attr->attr); > + if (error) > + goto error_out; sysfs_create_file() failed, so we need to clear all previously processed attrs and not the current one. > ++temp_attr; > } > } > + > + return 0; > + > +error_out: > + module_remove_modinfo_attrs(mod, --i); It says "call sysfs_remove_file() on all attrs ending with --i included (all correctly processed attrs). > return error; > } > > -static void module_remove_modinfo_attrs(struct module *mod) > +static void module_remove_modinfo_attrs(struct module *mod, int end) > { > struct module_attribute *attr; > int i; > > for (i = 0; (attr = &mod->modinfo_attrs[i]); i++) { > + if (end >= 0 && i > end) > + break; If end == 0, you break the loop without calling sysfs_remove_file(), which is a bug if you called module_remove_modinfo_attrs(mod, 0). Calling module_remove_modinfo_attrs(mod, i); in module_add_modinfo_attrs() under error_out label and changing the condition here to if (end >= 0 && i >= end) break; should work as expected. But let me ask another question and it might be more to Jessica. Why is there even a call to attr->free(mod); (if it exists) in module_remove_modinfo_attrs()? The same is in free_modinfo() (as opposed to setup_modinfo() where attr->setup(mod) is called. Is it because free_modinfo() is called only in load_module()'s error path, while module_remove_modinfo_attrs() is called even in free_module() path? kfree() checks for NULL pointer, so there is no bug, but it is certainly not nice and it calls for cleanup. But I may be missing something. Regards, Miroslav