FKIE_CVE-2025-39901
Vulnerability from fkie_nvd - Published: 2025-10-01 08:15 - Updated: 2026-10-19 21:10
Severity
7.1 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
7.1 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
7.1 (High) - CVSS:3.1/
Summary
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging
interface supported by the i40e driver since its early days by commit
02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless,
and which is implemented with questionable logic. They both use a static
256 byte buffer which is initialized to the empty string. In the case of
the 'command' file this buffer is literally never used and simply wastes
space. In the case of the 'netdev_ops' file, the last command written is
saved here.
On read, the files contents are presented as the name of the device
followed by a colon and then the contents of their respective static
buffer. For 'command' this will always be "<device>: ". For 'netdev_ops',
this will be "<device>: <last command written>". But note the buffer is
shared between all devices operated by this module. At best, it is mostly
meaningless information, and at worse it could be accessed simultaneously
as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions
about their use of snprintf and potential overflow that could result in
reading arbitrary kernel memory. For the 'command' file, this is definitely
impossible, since the static buffer is always zero and never written to.
For the 'netdev_ops' file, it does appear to be possible, if the user
carefully crafts the command input, it will be copied into the buffer,
which could be large enough to cause snprintf to truncate, which then
causes the copy_to_user to read beyond the length of the buffer allocated
by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would
cap the return to the number of bytes written, preventing an overflow. A
more involved fix would be to drop the mostly useless static buffers,
saving 512 bytes and modifying the read functions to stop needing those as
input.
Instead, lets just completely drop the read access to these files. These
are debug interfaces exposed as part of debugfs, and I don't believe that
dropping read access will break any script, as the provided output is
pretty useless. You can find the netdev name through other more standard
interfaces, and the 'netdev_ops' interface can easily result in garbage if
you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to
refactor its write function to avoid using the static buffer. Instead, use
the same logic as the i40e_dbg_command_write, with an allocated buffer.
Update the code to use this instead of the static buffer, and ensure we
free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on
multiple devices, and allows us to remove the now unused static buffer
along with removing the read access.
References
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.17 | |
| linux | linux_kernel | 6.17 | |
| linux | linux_kernel | 6.17 | |
| linux | linux_kernel | 6.17 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_debugfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6fd8b30a5cb84d74015bc651799d1ab1e047946c",
"status": "affected",
"version": "02e9c290814cc143ceccecb14eac3e7a05da745e",
"versionType": "git"
},
{
"lessThan": "ef40d9411469306e524e7887c51b709377e6ef65",
"status": "affected",
"version": "02e9c290814cc143ceccecb14eac3e7a05da745e",
"versionType": "git"
},
{
"lessThan": "70d3dad7d5ad077965d7a63eed1942b7ba49bfb4",
"status": "affected",
"version": "02e9c290814cc143ceccecb14eac3e7a05da745e",
"versionType": "git"
},
{
"lessThan": "7d190963b80f4cd99d7008615600aa7cc993c6ba",
"status": "affected",
"version": "02e9c290814cc143ceccecb14eac3e7a05da745e",
"versionType": "git"
},
{
"lessThan": "9fcdb1c3c4ba134434694c001dbff343f1ffa319",
"status": "affected",
"version": "02e9c290814cc143ceccecb14eac3e7a05da745e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_debugfs.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.12"
},
{
"lessThan": "3.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.183",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.148",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0EF56D34-531D-459A-8EE3-A89C28EF5DD6",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "3.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "548F104C-0F08-438B-9C97-64C903F0C678",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*",
"matchCriteriaId": "327D22EF-390B-454C-BD31-2ED23C998A1C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*",
"matchCriteriaId": "C730CD9A-D969-4A8E-9522-162AAF7C0EE9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*",
"matchCriteriaId": "39982C4B-716E-4B2F-8196-FA301F47807D",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*",
"matchCriteriaId": "340BEEA9-D70D-4290-B502-FBB1032353B1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0027command\u0027 and \u0027netdev_ops\u0027 debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\"i40e: debugfs interface\").\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0027command\u0027 file this buffer is literally never used and simply wastes\nspace. In the case of the \u0027netdev_ops\u0027 file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0027command\u0027 this will always be \"\u003cdevice\u003e: \". For \u0027netdev_ops\u0027,\nthis will be \"\u003cdevice\u003e: \u003clast command written\u003e\". But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0027t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0027command\u0027 file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0027netdev_ops\u0027 file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0027t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0027netdev_ops\u0027 interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0027netdev_ops\u0027 on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\ni40e: eliminar el acceso de lectura a los archivos debugfs\n\nLos archivos debugfs \u0027command\u0027 y \u0027netdev_ops\u0027 son una interfaz de depuraci\u00f3n heredada soportada por el controlador i40e desde sus inicios por el commit 02e9c290814c (\u0027i40e: debugfs interface\u0027).\n\nAmbos archivos debugfs proporcionan un gestor de lectura que es mayormente in\u00fatil y que est\u00e1 implementado con l\u00f3gica cuestionable. Ambos utilizan un b\u00fafer est\u00e1tico de 256 bytes que se inicializa a la cadena vac\u00eda. En el caso del archivo \u0027command\u0027, este b\u00fafer literalmente nunca se usa y simplemente desperdicia espacio. En el caso del archivo \u0027netdev_ops\u0027, el \u00faltimo comando escrito se guarda aqu\u00ed.\n\nAl leer, el contenido de los archivos se presenta como el nombre del dispositivo seguido de dos puntos y luego el contenido de su respectivo b\u00fafer est\u00e1tico. Para \u0027command\u0027 esto siempre ser\u00e1 \u0027\u003cdevice\u003e: \u0027. Para \u0027netdev_ops\u0027, esto ser\u00e1 \u0027\u003cdevice\u003e: \u003clast command written\u003e\u0027. Pero tenga en cuenta que el b\u00fafer se comparte entre todos los dispositivos operados por este m\u00f3dulo. En el mejor de los casos, es informaci\u00f3n mayormente sin sentido, y en el peor de los casos, podr\u00eda ser accedido simult\u00e1neamente ya que no parece haber ning\u00fan mecanismo de bloqueo.\n\nTambi\u00e9n hemos recibido recientemente m\u00faltiples informes para ambas funciones de lectura sobre su uso de snprintf y un posible desbordamiento que podr\u00eda resultar en la lectura de memoria arbitraria del kernel. Para el archivo \u0027command\u0027, esto es definitivamente imposible, ya que el b\u00fafer est\u00e1tico siempre es cero y nunca se escribe en \u00e9l. Para el archivo \u0027netdev_ops\u0027, s\u00ed parece ser posible, si el usuario elabora cuidadosamente la entrada del comando, se copiar\u00e1 en el b\u00fafer, que podr\u00eda ser lo suficientemente grande como para causar que snprintf trunque, lo que luego hace que copy_to_user lea m\u00e1s all\u00e1 de la longitud del b\u00fafer asignado por kzalloc.\n\nUna soluci\u00f3n m\u00ednima ser\u00eda reemplazar snprintf() con scnprintf(), lo que limitar\u00eda el retorno al n\u00famero de bytes escritos, evitando un desbordamiento. Una soluci\u00f3n m\u00e1s compleja ser\u00eda eliminar los b\u00faferes est\u00e1ticos mayormente in\u00fatiles, ahorrando 512 bytes y modificando las funciones de lectura para que dejen de necesitarlos como entrada.\n\nEn su lugar, simplemente eliminemos completamente el acceso de lectura a estos archivos. Estas son interfaces de depuraci\u00f3n expuestas como parte de debugfs, y no creo que eliminar el acceso de lectura rompa ning\u00fan script, ya que la salida proporcionada es bastante in\u00fatil. Se puede encontrar el nombre de netdev a trav\u00e9s de otras interfaces m\u00e1s est\u00e1ndar, y la interfaz \u0027netdev_ops\u0027 puede f\u00e1cilmente resultar en basura si se realizan escrituras simult\u00e1neas a m\u00faltiples dispositivos a la vez.\n\nPara eliminar correctamente el i40e_dbg_netdev_ops_buf, necesitamos refactorizar su funci\u00f3n de escritura para evitar usar el b\u00fafer est\u00e1tico. En su lugar, use la misma l\u00f3gica que i40e_dbg_command_write, con un b\u00fafer asignado. Actualice el c\u00f3digo para usar esto en lugar del b\u00fafer est\u00e1tico, y aseg\u00farese de liberar el b\u00fafer al salir. Esto corrige las escrituras simult\u00e1neas a \u0027netdev_ops\u0027 en m\u00faltiples dispositivos, y nos permite eliminar el b\u00fafer est\u00e1tico ahora sin usar junto con la eliminaci\u00f3n del acceso de lectura."
}
],
"id": "CVE-2025-39901",
"lastModified": "2026-10-19T21:10:00.160",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-39901",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-01-14T19:29:38.664446Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-10-01T08:15:32.860",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6fd8b30a5cb84d74015bc651799d1ab1e047946c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/70d3dad7d5ad077965d7a63eed1942b7ba49bfb4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7d190963b80f4cd99d7008615600aa7cc993c6ba"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9fcdb1c3c4ba134434694c001dbff343f1ffa319"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ef40d9411469306e524e7887c51b709377e6ef65"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.