linux-kernel - Re: [PATCH v4 4/4] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5405056.jcq3epAkXF@aspire.rjw.lan>
Date:   Mon, 12 Jun 2017 15:12:01 +0200
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Lv Zheng <lv.zheng@...el.com>
Cc:     "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Len Brown <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v4 4/4] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support

On Tuesday, May 09, 2017 01:57:54 PM Lv Zheng wrote:
> This patch adds acpi_put_table() to make all acpi_get_table() clone
> invocations balanced for sysfs ACPI table dump code.
> 
> Since Linux does not use all of the tables, this can help to reduce some
> usless memory mappings.
> 
> While originally, all tables will be remained to be mapped after a
> userspace acpidump execution, potentially causing problem on server
> platforms. With the new APIs, it is possible to release such useless table
> mappings.
> 
> Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> ---
>  drivers/acpi/sysfs.c | 41 +++++++++++++++++++++++++++++++----------
>  1 file changed, 31 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
> index 2bbf722..14425dc 100644
> --- a/drivers/acpi/sysfs.c
> +++ b/drivers/acpi/sysfs.c
> @@ -346,11 +346,22 @@ static ssize_t acpi_table_show(struct file *filp, struct kobject *kobj,
>  	return len;
>  }
>  
> +static bool acpi_table_has_multiple_instances(char *signature)
> +{
> +	acpi_status status;
> +	struct acpi_table_header *header;
> +
> +	status = acpi_get_table(signature, 2, &header);
> +	if (ACPI_FAILURE(status))
> +		return false;
> +	acpi_put_table(header);
> +	return true;
> +}

To be honest, I'm not convinced this is the best way to do that.

AFAICS there's no guarantee that the second instance would not go away after it
had been found and before this returned.

Thanks,
Rafael