CVE-2026-93168 (GCVE-0-2026-93168)
Vulnerability from cvelistv5 – Published: 2026-09-17 16:11 – Updated: 2026-09-17 16:11
VLAI
EPSS
VEX
Title
dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
Summary
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout
Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a
condition that is never fulfilled, the CPU busy-waits for prolonged time
and the timeout triggers only with a massive delay causing a CPU stall.
This happens due to a huge underestimation of wall clock time in
poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use
timekeeping in read_poll_timeout_atomic()") changed the behavior to no
longer use ktime_get at the expense of underestimation of wall clock
time which appears to be very large for delay_us=0. Instead of timing
out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout
takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for
loop in poll_timeout_us_atomic takes) which is in the range of several
minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero
value for delay_us. Use delay_us=10 to keep the delay in the hot path of
starting DMA transfers minimal but still avoid CPU stalls in case of
unexpected hardware failures.
One-off measurement with delay_us=0 causes the cpu to busy wait around 7
minutes in the timeout case. After applying this patch with delay_us=10
the measured timeout was 1053428 microseconds which is roughly
equivalent to the expected 1000000 microseconds specified in
XILINX_DMA_LOOP_COUNT.
Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.
Severity
No CVSS data available.
Assigner
References
Impacted products
2 products
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
9495f2648287029fb5545c34a0fa318426ebe84c , < 8b5654d317277e6e505c23f8fa7e415237fefc7f
(git)
Affected: 9495f2648287029fb5545c34a0fa318426ebe84c , < aa99c4d1d63bbc26a5fc4c667d89b2595743c19d (git) |
guessed | |
| Linux | Linux |
Affected:
4.6
Unaffected: 0 , < 4.6 (semver) Unaffected: 7.2.6 , ≤ 7.2.* (semver) Unaffected: 7.3-rc1 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/dma/xilinx/xilinx_dma.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "8b5654d317277e6e505c23f8fa7e415237fefc7f",
"status": "affected",
"version": "9495f2648287029fb5545c34a0fa318426ebe84c",
"versionType": "git"
},
{
"lessThan": "aa99c4d1d63bbc26a5fc4c667d89b2595743c19d",
"status": "affected",
"version": "9495f2648287029fb5545c34a0fa318426ebe84c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/dma/xilinx/xilinx_dma.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.6"
},
{
"lessThan": "4.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2.6",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.3-rc1",
"versionStartIncluding": "4.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout\n\nCurrently when calling xilinx_dma_poll_timeout with delay_us=0 and a\ncondition that is never fulfilled, the CPU busy-waits for prolonged time\nand the timeout triggers only with a massive delay causing a CPU stall.\n\nThis happens due to a huge underestimation of wall clock time in\npoll_timeout_us_atomic. Commit 7349a69cf312 (\"iopoll: Do not use\ntimekeeping in read_poll_timeout_atomic()\") changed the behavior to no\nlonger use ktime_get at the expense of underestimation of wall clock\ntime which appears to be very large for delay_us=0. Instead of timing\nout after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout\ntakes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for\nloop in poll_timeout_us_atomic takes) which is in the range of several\nminutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero\nvalue for delay_us. Use delay_us=10 to keep the delay in the hot path of\nstarting DMA transfers minimal but still avoid CPU stalls in case of\nunexpected hardware failures.\n\nOne-off measurement with delay_us=0 causes the cpu to busy wait around 7\nminutes in the timeout case. After applying this patch with delay_us=10\nthe measured timeout was 1053428 microseconds which is roughly\nequivalent to the expected 1000000 microseconds specified in\nXILINX_DMA_LOOP_COUNT.\n\nAdd a constant XILINX_DMA_POLL_DELAY_US for delay_us value."
}
],
"providerMetadata": {
"dateUpdated": "2026-09-17T16:11:59.904Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/8b5654d317277e6e505c23f8fa7e415237fefc7f"
},
{
"url": "https://git.kernel.org/stable/c/aa99c4d1d63bbc26a5fc4c667d89b2595743c19d"
}
],
"title": "dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-93168",
"datePublished": "2026-09-17T16:11:59.904Z",
"dateReserved": "2026-09-17T16:02:15.090Z",
"dateUpdated": "2026-09-17T16:11:59.904Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-93168\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-09-17T17:18:12.403\",\"lastModified\":\"2026-09-17T17:18:12.403\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ndmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout\\n\\nCurrently when calling xilinx_dma_poll_timeout with delay_us=0 and a\\ncondition that is never fulfilled, the CPU busy-waits for prolonged time\\nand the timeout triggers only with a massive delay causing a CPU stall.\\n\\nThis happens due to a huge underestimation of wall clock time in\\npoll_timeout_us_atomic. Commit 7349a69cf312 (\\\"iopoll: Do not use\\ntimekeeping in read_poll_timeout_atomic()\\\") changed the behavior to no\\nlonger use ktime_get at the expense of underestimation of wall clock\\ntime which appears to be very large for delay_us=0. Instead of timing\\nout after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout\\ntakes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for\\nloop in poll_timeout_us_atomic takes) which is in the range of several\\nminutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero\\nvalue for delay_us. Use delay_us=10 to keep the delay in the hot path of\\nstarting DMA transfers minimal but still avoid CPU stalls in case of\\nunexpected hardware failures.\\n\\nOne-off measurement with delay_us=0 causes the cpu to busy wait around 7\\nminutes in the timeout case. After applying this patch with delay_us=10\\nthe measured timeout was 1053428 microseconds which is roughly\\nequivalent to the expected 1000000 microseconds specified in\\nXILINX_DMA_LOOP_COUNT.\\n\\nAdd a constant XILINX_DMA_POLL_DELAY_US for delay_us value.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/dma/xilinx/xilinx_dma.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"9495f2648287029fb5545c34a0fa318426ebe84c\",\"lessThan\":\"8b5654d317277e6e505c23f8fa7e415237fefc7f\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"9495f2648287029fb5545c34a0fa318426ebe84c\",\"lessThan\":\"aa99c4d1d63bbc26a5fc4c667d89b2595743c19d\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/dma/xilinx/xilinx_dma.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.6\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.6\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.2.6\",\"lessThanOrEqual\":\"7.2.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.3-rc1\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/8b5654d317277e6e505c23f8fa7e415237fefc7f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/aa99c4d1d63bbc26a5fc4c667d89b2595743c19d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
"suse_vex": {
"aggregate_severity": "not set",
"current_release_date": "2026-09-18T00:11:13Z",
"cve": "CVE-2026-93168",
"id": "CVE-2026-93168",
"initial_release_date": "2026-09-18T00:11:13Z",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2026-93168",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-93168.json",
"version": "2"
}
}
}
Loading…
Loading…
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.
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.
Loading…