Answer in brief
CVE-2023-54065 records a High severity (CVSS 7.8) vulnerability in net: dsa: realtek: fix out-of-bounds access. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=aac94001067da183455d6d37959892744fa01d9d <cc0f9bb99735d2b68fac68f37b585d615728ce5b || >=aac94001067da183455d6d37959892744fa01d9d <fe668aa499b4b95425044ba11af9609db6ecf466 || >=aac94001067da183455d6d37959892744fa01d9d <b93eb564869321d0dffaf23fcc5c88112ed62466 | cc0f9bb99735d2b68fac68f37b585d615728ce5b, fe668aa499b4b95425044ba11af9609db6ecf466, b93eb564869321d0dffaf23fcc5c88112ed62466 |
| Linux/Linuxgeneric | 5.18 | Not reported |
Published upstream
Dec 24, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: fix out-of-bounds access The probe function sets priv->chip_data to (void *)priv + sizeof(*priv) with the expectation that priv has enough trailing space. However, only realtek-smi actually allocated this chip_data space. Do likewise in realtek-mdio to fix out-of-bounds accesses. These accesses likely went unnoticed so far, because of an (unused) buf[4096] member in struct realtek_priv, which caused kmalloc to round up the allocated buffer to a big enough size, so nothing of value was overwritten. With a different allocator (like in the barebox bootloader port of the driver) or with KASAN, the memory corruption becomes quickly apparent.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2023-54065 records a High severity (CVSS 7.8) vulnerability in net: dsa: realtek: fix out-of-bounds access. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=aac94001067da183455d6d37959892744fa01d9d <cc0f9bb99735d2b68fac68f37b585d615728ce5b || >=aac94001067da183455d6d37959892744fa01d9d <fe668aa499b4b95425044ba11af9609db6ecf466 || >=aac94001067da183455d6d37959892744fa01d9d <b93eb564869321d0dffaf23fcc5c88112ed62466 | cc0f9bb99735d2b68fac68f37b585d615728ce5b, fe668aa499b4b95425044ba11af9609db6ecf466, b93eb564869321d0dffaf23fcc5c88112ed62466 |
| Linux/Linuxgeneric | 5.18 | Not reported |
Published upstream
Dec 24, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: net: dsa: realtek: fix out-of-bounds access The probe function sets priv->chip_data to (void *)priv + sizeof(*priv) with the expectation that priv has enough trailing space. However, only realtek-smi actually allocated this chip_data space. Do likewise in realtek-mdio to fix out-of-bounds accesses. These accesses likely went unnoticed so far, because of an (unused) buf[4096] member in struct realtek_priv, which caused kmalloc to round up the allocated buffer to a big enough size, so nothing of value was overwritten. With a different allocator (like in the barebox bootloader port of the driver) or with KASAN, the memory corruption becomes quickly apparent.
Quoted source text, attributed separately from HOL analysis.