CVE-2026-23176: platform/x86: toshiba_haps: Fix memory leaks in add/remove routines
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: toshiba_haps: Fix memory leaks in add/remove routines
toshiba_haps_add() leaks the haps object allocated by it if it returns
an error after allocating that object successfully.
toshiba_haps_remove() does not free the object pointed to by
toshiba_haps before clearing that pointer, so it becomes unreachable
allocated memory.
Address these memory leaks by using devm_kzalloc() for allocating
the memory in question.
Security readout for executives and security teams
Plain-English summary
CVE-2026-23176 is a Linux kernel memory-leak issue in the Toshiba HAPS platform driver. The available sources describe leaked kernel memory during add or remove routines. No CVSS score, CWE, or active exploitation evidence is provided, so business urgency should be driven by affected kernel presence and normal patch governance.
Executive priority
Handle through standard kernel patch management unless your fleet includes affected Toshiba platform systems at scale. There is no source-backed evidence of active exploitation, but kernel memory leaks can affect reliability and should not be ignored.
Technical view
The flaw is in platform/x86 toshiba_haps. toshiba_haps_add() can leak its allocated haps object after allocation if later error handling returns. toshiba_haps_remove() clears the global pointer without freeing the allocated object. The kernel fix changes allocation to devm_kzalloc(), tying cleanup to device-managed lifetime.
Likely exposure
Exposure appears limited to Linux systems with affected kernel versions and the toshiba_haps driver present or used. This is most relevant to Toshiba laptop or platform-management environments. The source bundle does not establish remote reachability, privilege requirements, or exploit prerequisites.
Exploitation context
CISA KEV status is false in the provided data, and the source bundle contains no cited evidence of active exploitation or public weaponization. Treat exploitation context as unknown beyond the described kernel memory-leak behavior.
Researcher notes
Evidence is narrow: commit descriptions identify memory leaks and the devm_kzalloc() remediation, but no CVSS, CWE, exploitability analysis, or attack path is included. Avoid claiming confidentiality or code-execution impact from the supplied sources.
Mitigation direction
Apply Linux vendor kernel updates that include the referenced stable fixes.
Prioritize systems using Toshiba platform hardware or the toshiba_haps driver.
Check distribution advisories before assuming exact affected package versions.
Track exceptions where kernel updates are delayed or vendor guidance is pending.
Validation and detection
Inventory Linux kernel versions against vendor advisories and fixed stable commits.
Confirm whether the toshiba_haps driver is present or relevant to deployed hardware.
Verify updated kernel packages include the CVE-2026-23176 fix.
Document systems where exposure cannot be confirmed from available data.
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.
cve · low confidence lookup
CVE-2026-23176 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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
8Source 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.
Feb 14, 2026, 16:27 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.