FKIE_CVE-2026-90183
Vulnerability from fkie_nvd - Published: 2026-09-17 17:17 - Updated: 2026-09-17 17:17
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: clear delay state when freeing policy data
io.latency can throttle a group which has no latency target of its own.
When a sibling misses its target, check_scale_change() scales down its
peers, and a peer that reaches queue depth one gets blkcg_use_delay()
called on it on every further scale-down, even with min_lat_nsec == 0.
iolatency_pd_offline() resets the target through
iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero
to zero transition, so it never clears such a peer. Freeing the policy
data then leaves blkg->use_delay set and blkcg->congestion_count
elevated with nothing left that can drop it.
blk_cgroup_congested() then returns true for every task in that cgroup
and its descendants for as long as the cgroup lives: page_cache_sync_ra()
cuts readahead to a single page, page_cache_async_ra() skips it
altogether, and __folio_throttle_swaprate() takes swap_avail_lock and
schedules a throttle on anonymous folio allocation.
Clear the delay in iolatency_pd_free(). By then bio-held blkg
references have drained, or the queue is frozen for policy
deactivation, so check_scale_change() cannot re-arm it. The free
callback can also see policy data which was never attached to a blkg,
hence the pd->blkg check.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"block/blk-iolatency.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "02f1b90ab33ef99c89dd96a385b432ff57abc64d",
"status": "affected",
"version": "d70675121546c35feaceebf7ed9caed8716640f3",
"versionType": "git"
},
{
"lessThan": "8935bf22c0a0db517a7f72f7097300e05dd852f5",
"status": "affected",
"version": "d70675121546c35feaceebf7ed9caed8716640f3",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"block/blk-iolatency.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.19"
},
{
"lessThan": "4.19",
"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"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-iolatency: clear delay state when freeing policy data\n\nio.latency can throttle a group which has no latency target of its own.\nWhen a sibling misses its target, check_scale_change() scales down its\npeers, and a peer that reaches queue depth one gets blkcg_use_delay()\ncalled on it on every further scale-down, even with min_lat_nsec == 0.\n\niolatency_pd_offline() resets the target through\niolatency_set_min_lat_nsec(), which clears the delay only on a nonzero\nto zero transition, so it never clears such a peer. Freeing the policy\ndata then leaves blkg-\u003euse_delay set and blkcg-\u003econgestion_count\nelevated with nothing left that can drop it.\n\nblk_cgroup_congested() then returns true for every task in that cgroup\nand its descendants for as long as the cgroup lives: page_cache_sync_ra()\ncuts readahead to a single page, page_cache_async_ra() skips it\naltogether, and __folio_throttle_swaprate() takes swap_avail_lock and\nschedules a throttle on anonymous folio allocation.\n\nClear the delay in iolatency_pd_free(). By then bio-held blkg\nreferences have drained, or the queue is frozen for policy\ndeactivation, so check_scale_change() cannot re-arm it. The free\ncallback can also see policy data which was never attached to a blkg,\nhence the pd-\u003eblkg check."
}
],
"id": "CVE-2026-90183",
"lastModified": "2026-09-17T17:17:12.710",
"metrics": {},
"published": "2026-09-17T17:17:12.710",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/02f1b90ab33ef99c89dd96a385b432ff57abc64d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8935bf22c0a0db517a7f72f7097300e05dd852f5"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
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…
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…