EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
- •No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS v2: —Exploit: None knownExposed services: Not assessed
No fix is confirmed yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for the fix.
The CVE record's CNA (kernel.org) lists Linux versions 4.14.177 up to but not including 4.15, 4.19.118 up to but not including 4.20 and 5.4.35 up to but not including 5.5 as affected, and Linux versions before 5.7 and 7.4-rc1 and later as unaffected. No release containing a fix is confirmed on record.
In the Linux kernel, the following vulnerability has been resolved:
keys: Protect the read method check against type removal
keyctl_read_key() checks key->type->read without holding key->sem.
A reference keeps the key alive, but does not pin the module containing
its type. A surviving RxRPC key can therefore be read while AF_RXRPC
is being unloaded:
KEYCTL_READ task Module unload and key GC
---------------- ------------------------
lookup_user_key()
permission / possession checks
load key->type
af_rxrpc_exit()
unregister_key_type()
GC: down_write(key->sem)
GC: retype to key_type_dead
GC: up_write(key->sem)
unregister_key_type() returns
free_module()
read saved type's read member
The final access can read freed module storage. The read invocation in
__keyctl_read_key() is already protected by key->sem, but the earlier
method check is outside that critical section.
Move the method check into __keyctl_read_key(), after key_validate() and
under its existing read hold on key->sem. The check and invocation then
use the same protected type for length queries and every read retry.
The GC cannot retype the key until the semaphore is released, and type
unregistration waits for that GC pass before the module can be freed.
Return -EOPNOTSUPP when validation succeeds and the type has no read
method. A temporary buffer may now be allocated before this result;
allocation and copying to userspace remain outside the semaphore.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
- EG Severity
- Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
- EG Likelihood
- 0.2% within 30 daysSource: FIRST EPSS (model v2026.06.15, score date 2026-11-03). FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.
The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it