GHSA-4X4P-C635-2M6R
Vulnerability from github – Published: 2025-05-08 09:30 – Updated: 2025-11-13 00:30In the Linux kernel, the following vulnerability has been resolved:
mei: vsc: Fix fortify-panic caused by invalid counted_by() use
gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[] and the vsc-tp.c code is using this in a wrong way. len does not contain the available size in the buffer, it contains the actual packet length without the crc. So as soon as vsc_tp_xfer() tries to add the crc to buf[] the fortify-panic handler gets triggered:
[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0 [ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [ 80.843175] __fortify_panic+0x9/0xb [ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei]
The easiest fix would be to just drop the counted-by but with the exception of the ack buffer in vsc_tp_xfer_helper() which only contains enough room for the packet-header, all other uses of vsc_tp_packet always use a buffer of VSC_TP_MAX_XFER_SIZE bytes for the packet.
Instead of just dropping the counted-by, split the vsc_tp_packet struct definition into a header and a full-packet definition and use a fixed size buf[] in the packet definition, this way fortify-source buffer overrun checking still works when enabled.
{
"affected": [],
"aliases": [
"CVE-2025-37816"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-08T07:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmei: vsc: Fix fortify-panic caused by invalid counted_by() use\n\ngcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]\nand the vsc-tp.c code is using this in a wrong way. len does not contain\nthe available size in the buffer, it contains the actual packet length\n*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to\nbuf[] the fortify-panic handler gets triggered:\n\n[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0\n[ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50\n...\n[ 80.843175] __fortify_panic+0x9/0xb\n[ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw]\n[ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90\n[ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110\n[ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc]\n[ 80.843270] mei_reset+0x11d/0x420 [mei]\n\nThe easiest fix would be to just drop the counted-by but with the exception\nof the ack buffer in vsc_tp_xfer_helper() which only contains enough room\nfor the packet-header, all other uses of vsc_tp_packet always use a buffer\nof VSC_TP_MAX_XFER_SIZE bytes for the packet.\n\nInstead of just dropping the counted-by, split the vsc_tp_packet struct\ndefinition into a header and a full-packet definition and use a fixed\nsize buf[] in the packet definition, this way fortify-source buffer\noverrun checking still works when enabled.",
"id": "GHSA-4x4p-c635-2m6r",
"modified": "2025-11-13T00:30:16Z",
"published": "2025-05-08T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37816"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00f1cc14da0f06d2897b8c528df7c7dcf1b8da50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e243378f27cc7d11682a3ad720228b0723affa5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac04663c67f244810b3492e9ecd9f7cdbefeca2d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.
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.
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.