usb: typec: tcpm: Correct the PDO counting in pd_set
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Correct the PDO counting in pd_set Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one. When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected). "nr_src_pdo" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.8.8
- CVEs
- CVE-2024-26995
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 2 Nov 2026, 19:05 UTC · Revision 1
Source evidence
usb: typec: tcpm: Correct the PDO counting in pd_set
core-osv · Original sourcePublished 1 May 2024, 05:28 UTC
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Correct the PDO counting in pd_set Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one. When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected). "nr_src_pdo" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets.
osv:CVE-2024-26995
Kernel
Fixed versions: 6.8.8
Complete source record
{
"id": "a185e47cd06d04e9e829bb24f69e4e0a178d455b70f8648ee92473cde1a5aa70",
"url": "https://osv.dev/vulnerability/CVE-2024-26995",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "usb: typec: tcpm: Correct the PDO counting in pd_set",
"summary": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Correct the PDO counting in pd_set Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one. When doing the power negotiation, TCPM relies on the \"nr_snk_pdo\" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected). \"nr_src_pdo\" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets.",
"evidence": "osv:CVE-2024-26995",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.8.8",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2024-26995",
"aliases": [
"CVE-2024-26995"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "cd099cde4ed264403b434d8344994f97ac2a4349"
},
{
"fixed": "f3da3192cdd3fefe213390e976eec424a8e270b5"
},
{
"fixed": "c4128304c2169b4664ed6fb6200f228cead2ab70"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26995.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.8.0"
},
{
"fixed": "6.8.8"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26995.json"
}
}
],
"modified": "2026-10-28T02:30:22.699627952Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/c4128304c2169b4664ed6fb6200f228cead2ab70",
"https://git.kernel.org/stable/c/f3da3192cdd3fefe213390e976eec424a8e270b5",
"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53/",
"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY/",
"https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW/",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26995.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-26995",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26995.json"
}
},
"related_cves": [
{
"value": "CVE-2024-26995",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 488947,
"published_at": "2024-05-01T05:28:12.105+00:00"
}