ghsa-4x4p-c635-2m6r
Vulnerability from github
In 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": null
},
"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-05-08T09:30:24Z",
"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": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.