dmaengine: nbpfaxi: Fix memory corruption in probe()
In the Linux kernel, the following vulnerability has been resolved: dmaengine: nbpfaxi: Fix memory corruption in probe() The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has "num_channels" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the "chan" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.241, 5.15.190, 5.4.297, 6.1.147, 6.12.40, 6.15.8, 6.6.100
- CVEs
- CVE-2025-38538
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 5 Nov 2026, 04:24 UTC · Revision 1
Source evidence
dmaengine: nbpfaxi: Fix memory corruption in probe()
core-osv · Original sourcePublished 16 Aug 2025, 11:12 UTC
In the Linux kernel, the following vulnerability has been resolved: dmaengine: nbpfaxi: Fix memory corruption in probe() The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has "num_channels" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the "chan" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.
osv:CVE-2025-38538
Kernel
Fixed versions: 5.4.297, 5.10.241, 5.15.190, 6.1.147, 6.6.100, 6.12.40, 6.15.8
Complete source record
{
"id": "6db2b80ac77ce7bd703f26291783a30fff5e756fcb87b2482da582c939a57d8a",
"url": "https://osv.dev/vulnerability/CVE-2025-38538",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "dmaengine: nbpfaxi: Fix memory corruption in probe()",
"summary": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: nbpfaxi: Fix memory corruption in probe() The nbpf->chan[] array is allocated earlier in the nbpf_probe() function and it has \"num_channels\" elements. These three loops iterate one element farther than they should and corrupt memory. The changes to the second loop are more involved. In this case, we're copying data from the irqbuf[] array into the nbpf->chan[] array. If the data in irqbuf[i] is the error IRQ then we skip it, so the iterators are not in sync. I added a check to ensure that we don't go beyond the end of the irqbuf[] array. I'm pretty sure this can't happen, but it seemed harmless to add a check. On the other hand, after the loop has ended there is a check to ensure that the \"chan\" iterator is where we expect it to be. In the original code we went one element beyond the end of the array so the iterator wasn't in the correct place and it would always return -EINVAL. However, now it will always be in the correct place. I deleted the check since we know the result.",
"evidence": "osv:CVE-2025-38538",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.4.297",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.241",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.190",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.147",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.100",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.40",
"evidence": "/affected/1/ranges"
},
{
"value": "6.15.8",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-38538",
"aliases": [
"CVE-2025-38538"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "b45b262cefd5b8eb2ba88d20e5bd295881293894"
},
{
"fixed": "84fff8e6f11b9af1407e273995b5257d99ff0cff"
},
{
"fixed": "aec396b4f736f3f8d2c28a9cd2924a4ada57ae87"
},
{
"fixed": "24861ef8b517a309a4225f2793be0cd8fa0bec9e"
},
{
"fixed": "f366b36c5e3ce29c9a3c8eed3d1631908e4fc8bb"
},
{
"fixed": "4bb016438335ec02b01f96bf1367378c2bfe03e5"
},
{
"fixed": "122160289adf8ebf15060f1cbf6265b55a914948"
},
{
"fixed": "d6bbd67ab5de37a74ac85c83c5a26664b62034dd"
},
{
"fixed": "188c6ba1dd925849c5d94885c8bbdeb0b3dcf510"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-38538.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "5.4.297"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.241"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.190"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.147"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.100"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.40"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.15.8"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-38538.json"
}
}
],
"modified": "2026-10-28T02:30:42.823401039Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/122160289adf8ebf15060f1cbf6265b55a914948",
"https://git.kernel.org/stable/c/188c6ba1dd925849c5d94885c8bbdeb0b3dcf510",
"https://git.kernel.org/stable/c/24861ef8b517a309a4225f2793be0cd8fa0bec9e",
"https://git.kernel.org/stable/c/4bb016438335ec02b01f96bf1367378c2bfe03e5",
"https://git.kernel.org/stable/c/84fff8e6f11b9af1407e273995b5257d99ff0cff",
"https://git.kernel.org/stable/c/aec396b4f736f3f8d2c28a9cd2924a4ada57ae87",
"https://git.kernel.org/stable/c/d6bbd67ab5de37a74ac85c83c5a26664b62034dd",
"https://git.kernel.org/stable/c/f366b36c5e3ce29c9a3c8eed3d1631908e4fc8bb",
"https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html",
"https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/38xxx/CVE-2025-38538.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-38538",
"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/2025/38xxx/CVE-2025-38538.json"
}
},
"related_cves": [
{
"value": "CVE-2025-38538",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 510236,
"published_at": "2025-08-16T11:12:30.878+00:00"
}