Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230114085053.72059-1-W_Armin@gmx.de> <20230114085053.72059-3-W_Armin@gmx.de>
 <CAJZ5v0h2vTAUovMoEoWVX2gJQiJS6C9PSYzMqQMtxPusgdHBMQ@mail.gmail.com> <90f1270d-3c37-088b-98ac-a08caba685e8@gmx.de>
In-Reply-To: <90f1270d-3c37-088b-98ac-a08caba685e8@gmx.de>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Wed, 18 Jan 2023 16:00:53 +0100
Message-ID: <CAJZ5v0hKaet9sB6Xr8J5Ke848nF1T=T8k9H0Uyfm5J0MLNHD-w@mail.gmail.com>
Subject: Re: [PATCH 2/4] ACPI: battery: Fix buffer overread if not NUL-terminated
To:     Armin Wolf <W_Armin@gmx.de>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>, lenb@kernel.org,
        linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jan 17, 2023 at 10:01 PM Armin Wolf <W_Armin@gmx.de> wrote:
>
> Am 17.01.23 um 15:42 schrieb Rafael J. Wysocki:
>
> > On Sat, Jan 14, 2023 at 9:51 AM Armin Wolf <W_Armin@gmx.de> wrote:
> >> If the buffer containing string data is not NUL-terminated
> >> (which is perfectly legal according to the ACPI specification),
> >> the acpi battery driver might not honor its length.
> > Note that this is about extracting package entries of type ACPI_TYPE_BUFFER.
> >
> > And please spell ACPI in capitals.
> >
> >> Fix this by limiting the amount of data to be copied to
> >> the buffer length while also using strscpy() to make sure
> >> that the resulting string is always NUL-terminated.
> > OK
> >
> >> Also use '\0' instead of a plain 0.
> > Why?  It's a u8, not a char.
> >
> >> Signed-off-by: Armin Wolf <W_Armin@gmx.de>
> >> ---
> >>   drivers/acpi/battery.c | 23 ++++++++++++++++-------
> >>   1 file changed, 16 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> >> index fb64bd217d82..9f6daa9f2010 100644
> >> --- a/drivers/acpi/battery.c
> >> +++ b/drivers/acpi/battery.c
> >> @@ -438,15 +438,24 @@ static int extract_package(struct acpi_battery *battery,
> >>                  if (offsets[i].mode) {
> >>                          u8 *ptr = (u8 *)battery + offsets[i].offset;
> > I would add
> >
> > u32 len = 32;
> >
> >> -                       if (element->type == ACPI_TYPE_STRING ||
> >> -                           element->type == ACPI_TYPE_BUFFER)
> >> +                       switch (element->type) {
> > And here I would do
> >
> > case ACPI_TYPE_BUFFER:
> >          if (len > element->buffer.length + 1)
> >                  len = element->buffer.length + 1;
> >
> >          fallthrough;
> > case ACPI_TYPE_STRING:
> >          strscpy(ptr, element->buffer.pointer, len);
> >          break;
> > case ACPI_TYPE_INTEGER:
> >
> > and so on.
>
> But wouldn't this cause the ACPI string object to be accessed the wrong way
> (buffer.pointer instead of string.pointer)?

I meant string.pointer, like in the original code, but this doesn't
matter really, because the value of the pointer is the same.