From: Hans de Goede <hansg@kernel.org>
To: Kees Cook <kees@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
zepta <z3ptaa@gmail.com>, Ard Biesheuvel <ardb@kernel.org>,
Andy Shevchenko <andy@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org, linux-staging@lists.linux.dev,
Bartosz Golaszewski <brgl@bgdev.pl>,
Abraham Samuel Adekunle <abrahamadekunle50@gmail.com>,
Thomas Andreatta <thomasandreatta2000@gmail.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()
Date: Tue, 5 Aug 2025 11:02:08 +0200 [thread overview]
Message-ID: <cdb31c16-74c3-43e4-bf9f-da7f48ab8d46@kernel.org> (raw)
In-Reply-To: <202507281745.0D675898@keescook>
Hi Kees,
On 29-Jul-25 2:46 AM, Kees Cook wrote:
> On Sat, Jul 26, 2025 at 02:24:51PM +0200, Hans de Goede wrote:
>> Hi Kees,
>>
>> On 24-Jul-25 10:08 AM, Kees Cook wrote:
>>> When gmin_get_config_var() calls efi.get_variable() and the EFI variable
>>> is larger than the expected buffer size, two behaviors combine to create
>>> a stack buffer overflow:
>>>
>>> 1. gmin_get_config_var() does not return the proper error code when
>>> efi.get_variable() fails. It returns the stale 'ret' value from
>>> earlier operations instead of indicating the EFI failure.
>>>
>>> 2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates
>>> *out_len to the required buffer size but writes no data to the output
>>> buffer. However, due to bug #1, gmin_get_var_int() believes the call
>>> succeeded.
>>>
>>> The caller gmin_get_var_int() then performs:
>>> - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack
>>> - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64
>>> - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size
>>> - Due to bug #1, thinks call succeeded with len=required_size
>>> - Executes val[len] = 0, writing past end of 65-byte stack buffer
>>>
>>> This creates a stack buffer overflow when EFI variables are larger than
>>> 64 bytes. Since EFI variables can be controlled by firmware or system
>>> configuration, this could potentially be exploited for code execution.
>>>
>>> Fix the bug by returning proper error codes from gmin_get_config_var()
>>> based on EFI status instead of stale 'ret' value.
>>>
>>> The gmin_get_var_int() function is called during device initialization
>>> for camera sensor configuration on Intel Bay Trail and Cherry Trail
>>> platforms using the atomisp camera stack.
>>>
>>> Reported-by: zepta <z3ptaa@gmail.com>
>>> Closes: https://lore.kernel.org/all/CAPBS6KoQyM7FMdPwOuXteXsOe44X4H3F8Fw+y_qWq6E+OdmxQA@mail.gmail.com
>>> Fixes: 38d4f74bc148 ("media: atomisp_gmin_platform: stop abusing efivar API")
>>> Signed-off-by: Kees Cook <kees@kernel.org>
>>
>> Thanks, patch looks good to me:
>>
>> Reviewed-by: Hans de Goede <hansg@kernel.org>
>>
>> I've already send an atomisp pull-request for 6.17 out
>> and this is already in media-committers/next now and
>> the media subsystem is typically not good in merging
>> fixes just before the merge window.
>>
>> Kees, the file touched here is unchanged in
>> media-committers/next vs Linus' latest master, can you
>> send this fix to Linus yourself ?
>
> I apologize; this slipped through the cracks. Shall I take it for -rc2,
> or do you want to snag it?
I'm just back from vacation and I see you've send this
to Linus already:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/staging/media/atomisp?id=ee4cf798202d285dcbe85e4467a094c44f5ed8e6
Which is great, thank you.
Regards,
Hans
prev parent reply other threads:[~2025-08-05 9:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 8:08 [PATCH] staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int() Kees Cook
2025-07-26 12:24 ` Hans de Goede
2025-07-29 0:46 ` Kees Cook
2025-08-05 9:02 ` Hans de Goede [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cdb31c16-74c3-43e4-bf9f-da7f48ab8d46@kernel.org \
--to=hansg@kernel.org \
--cc=abrahamadekunle50@gmail.com \
--cc=andy@kernel.org \
--cc=ardb@kernel.org \
--cc=brgl@bgdev.pl \
--cc=gregkh@linuxfoundation.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=thomasandreatta2000@gmail.com \
--cc=z3ptaa@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.