CVE-2025-38585: staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()
In the Linux kernel, the following vulnerability has been resolved:
staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()
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.
Security readout for executives and security teams
Plain-English summary
CVE-2025-38585 is a Linux kernel stack buffer overflow in the staging atomisp camera driver path. It can occur during camera sensor initialization when an EFI variable is larger than expected. The source says this could potentially enable code execution, but no active exploitation is documented in the provided sources.
Executive priority
Prioritize remediation for older Intel tablet, embedded, kiosk, or specialty systems that rely on atomisp cameras. Broad enterprise exposure is likely lower than a general Linux kernel flaw, but kernel memory corruption with possible code execution warrants tracked patching.
Technical view
The flaw is in gmin_get_var_int() and gmin_get_config_var(). An EFI_BUFFER_TOO_SMALL response can update the length without filling the buffer, while stale success handling causes val[len] = 0 to write beyond a 65-byte stack buffer. The fix returns proper EFI-related errors from gmin_get_config_var().
Likely exposure
Exposure appears limited to Linux systems using the atomisp camera stack on Intel Bay Trail and Cherry Trail platforms. The provided affected data points to Linux kernel ranges before referenced stable fixes, with the vulnerability introduced from commit 38d4f74bc14847491d07bd745dc4a2c274f4987d.
Exploitation context
The source states EFI variables can be controlled by firmware or system configuration, making exploitation potentially possible. However, the bundle provides no CVSS score, no CWE classification, no public exploit evidence, and KEV is false. Treat exploitation status as unconfirmed.
Researcher notes
The evidence supports a bounds error caused by incorrect EFI error propagation, not a complete exploit chain. Key unknowns are practical attacker control of EFI variables, reachable platform configurations, privilege requirements, and whether downstream kernels ship atomisp enabled.
Mitigation direction
Update to a kernel or distribution package containing the referenced stable fix.
Prioritize affected Intel Bay Trail and Cherry Trail systems using atomisp camera support.
Check distribution advisories for backported fixes rather than relying only on version strings.
Review firmware and platform configuration controls for EFI variable management.
Track CVE and kernel stable references for any revised severity or exploit information.
Validation and detection
Inventory Linux kernel versions on Bay Trail and Cherry Trail devices.
Check whether the atomisp camera stack is present and used.
Confirm vendor kernels include one of the referenced stable commits or equivalent backport.
Review boot and device initialization logs for atomisp camera initialization paths.
Record systems where patch status cannot be confirmed for remediation tracking.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
description · low confidence lookup
Execution behavior lookup
The CVE wording references code or command execution, so execution technique review may help defensive triage. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Aug 19, 2025, 17:03 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.