FKIE_CVE-2026-98398
Vulnerability from fkie_nvd - Published: 2026-10-14 14:17 - Updated: 2026-10-19 10:18
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
locking/lockdep: Invalidate stale class_cache entries for zapped classes
syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in
hlock_class() due to an invalid class_idx:
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203
Call Trace:
<IRQ>
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173
tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291
tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
...
When a lock class is zapped (e.g. during module unload or key
unregistration), zap_class() clears the class's bit in
lock_classes_in_use and removes it from the class hash table.
However, existing lockdep_map instances embedded in data structures
may still retain a pointer to the zapped class in their class_cache[]
array.
When __lock_acquire() subsequently runs on such a lock, it finds
lock->class_cache[subclass] != NULL, skipping register_lock_class()
and assigning hlock->class_idx to the index of the zapped class. When
check_wait_context() or hlock_class() inspects the held_lock, it finds
!test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if
the zapped slot is subsequently re-allocated to an unrelated lock key,
the stale class_cache entry would erroneously match the unrelated
class (ABA issue).
Add lock_class_cache_is_valid() to validate that the cached class is
within lock_classes bounds, still allocated in lock_classes_in_use
(using uninstrumented arch_test_bit() in __always_inline context so it
is safe in noinstr contexts like match_held_lock()), and that
class->key matches the expected subkey (taking lockdep_set_subclass()
overrides into account). Also use READ_ONCE()/WRITE_ONCE() when
accessing class_cache[]. If the entry is invalid or stale, fall back
to register_lock_class() / look_up_lock_class().
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/locking/lockdep.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f8a1281ab82df5b51fd0384354d4b21daf2b7af0",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
},
{
"lessThan": "1c9d664e2e067fca69e5a41d68e23bbc66a583fe",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
},
{
"lessThan": "6bc345f6d81ebe22e0f355c2a21d7e29691f9332",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
},
{
"lessThan": "f63c86e9d267629758adaba18579e784ddd63c32",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
},
{
"lessThan": "c7acfb04c7e2e2dea248282b21373d93296644dd",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
},
{
"lessThan": "baa320fbb2f9fea50f5632a307da8ce84fbef5bd",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
},
{
"lessThan": "02c6be7d675b21d81f0ba3a524346850a8c0e3bf",
"status": "affected",
"version": "a0b0fd53e1e67639b303b15939b9c653dbe7a8c4",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"kernel/locking/lockdep.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.1"
},
{
"lessThan": "5.1",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.222",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.189",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.158",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.111",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"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\nlocking/lockdep: Invalidate stale class_cache entries for zapped classes\n\nsyzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in\nhlock_class() due to an invalid class_idx:\n\n WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203\n Workqueue: wg-crypt-wg0 wg_packet_tx_worker\n RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]\n RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]\n RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203\n Call Trace:\n \u003cIRQ\u003e\n lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886\n _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173\n tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291\n tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325\n ...\n\nWhen a lock class is zapped (e.g. during module unload or key\nunregistration), zap_class() clears the class\u0027s bit in\nlock_classes_in_use and removes it from the class hash table.\nHowever, existing lockdep_map instances embedded in data structures\nmay still retain a pointer to the zapped class in their class_cache[]\narray.\n\nWhen __lock_acquire() subsequently runs on such a lock, it finds\nlock-\u003eclass_cache[subclass] != NULL, skipping register_lock_class()\nand assigning hlock-\u003eclass_idx to the index of the zapped class. When\ncheck_wait_context() or hlock_class() inspects the held_lock, it finds\n!test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if\nthe zapped slot is subsequently re-allocated to an unrelated lock key,\nthe stale class_cache entry would erroneously match the unrelated\nclass (ABA issue).\n\nAdd lock_class_cache_is_valid() to validate that the cached class is\nwithin lock_classes bounds, still allocated in lock_classes_in_use\n(using uninstrumented arch_test_bit() in __always_inline context so it\nis safe in noinstr contexts like match_held_lock()), and that\nclass-\u003ekey matches the expected subkey (taking lockdep_set_subclass()\noverrides into account). Also use READ_ONCE()/WRITE_ONCE() when\naccessing class_cache[]. If the entry is invalid or stale, fall back\nto register_lock_class() / look_up_lock_class()."
}
],
"id": "CVE-2026-98398",
"lastModified": "2026-10-19T10:18:44.480",
"metrics": {},
"published": "2026-10-14T14:17:50.760",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/02c6be7d675b21d81f0ba3a524346850a8c0e3bf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1c9d664e2e067fca69e5a41d68e23bbc66a583fe"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6bc345f6d81ebe22e0f355c2a21d7e29691f9332"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/baa320fbb2f9fea50f5632a307da8ce84fbef5bd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c7acfb04c7e2e2dea248282b21373d93296644dd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f63c86e9d267629758adaba18579e784ddd63c32"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f8a1281ab82df5b51fd0384354d4b21daf2b7af0"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.