svcrdma: Validate Read chunk positions before reconstruction
Why It Matters
Analysis dossierWhy It Matters
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Validate Read chunk positions before reconstruction The RPC/RDMA Read chunk position field is supplied by the remote client and stored verbatim in the parsed chunk list. xdr_count_read_segments() checks only 4-byte alignment; it never compares the position against the received inline body length. In the single-chunk path, svc_rdma_read_complete_one() splits the head and tail kvecs at ch_position. A position past the inline body underflows the tail length, exposing adjacent slab memory to the upper XDR decoder. In the multi-chunk path, svc_rdma_read_multiple_chunks() computes gap lengths between chunks as unsigned subtractions from ch_position. Overlapping Read chunks cause these subtractions to underflow. A final position past the inline body likewise underflows the trailing gap length. svc_rdma_copy_inline_range() then copies past the receive buffer into request pages that are returned to the client through the Reply channel. Bound inline-range copies in svc_rdma_copy_inline_range() against the decoded inline RPC body saved in rc_saved_arg. Reject a single Read chunk positioned beyond that body, and reject multi-chunk lists where accumulated read bytes exceed the next chunk's position. Apply the same position and overlap checks in the call-chunk interleaving path.
High Severity / Review
Unknown
Unknown
Risk basis: SOC ecosystem technology relevance; CRITICAL severity; Critical CVSS without confirmed KEV exploitation
Affected Products & Remediation
3 source-backed products- azl3 kernel 6.6.157.1-1 on Azure Linux 3.0 · version range not provided by source · Microsoft MSRC · Source
- azl3 kernel 6.6.150.1-1 on Azure Linux 3.0 · version range not provided by source · Microsoft MSRC · Source
- azl3 kernel 6.6.152.1-1 on Azure Linux 3.0 · version range not provided by source · Microsoft MSRC · Source
Vendor or catalog guidance (source)
- Microsoft MSRC: Release Notes
Known exploitation (source facts)
Only what a source states. Unknown means no source has said either way; it is not "not exploited".
- CISA KEV
- Unknown
- Exploited (source statement)
- Unknown
- Publicly disclosed (source)
- Unknown
Suggested hunting (rule-based inference)
SecOps Signal recommendation (rule-based inference). These steps are hunting hypotheses from the vulnerability class; they do not state or imply that exploitation occurred here or anywhere.
Matched network-unauthenticated (CVSS AV:N, CVSS PR:N, CVSS UI:N)
Exposure
- Identify devices reporting this CVE and note which expose the affected service to untrusted networks.Telemetry: DeviceTvmSoftwareVulnerabilities · A network-reachable, no-privilege vector makes internet-facing instances the first exposure question. · Rule network-unauthenticated
Exploitation evidence
- Review inbound connections to the affected service from unexpected sources since the advisory date.Telemetry: DeviceNetworkEvents · Hunting hypothesis from the CVSS vector; it does not show that exploitation occurred. · Rule network-unauthenticated
Response
- Confirm the source-stated update is installed and the CVE is no longer reported.Telemetry: DeviceTvmSoftwareVulnerabilities · A follow-up inventory check verifies remediation. · Rule network-unauthenticated
CISA KEV Record
CISA KEV status was not determined for this record.
Change History & Source Data
— No recorded material change
- CNA / source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- Record status · verification
- UPDATED · NVD API
- CPE
- Unknown
Evidence & Provenance
Linked by the query's stored exact CVE association. Review required tables and validation status before use.
DeviceTvmSoftwareVulnerabilities| where CveId == "CVE-2026-89526"| project DeviceId, DeviceName, OSPlatform, OSVersion, SoftwareVendor, SoftwareName, SoftwareVersion, CveId, VulnerabilitySeverityLevel, RecommendedSecurityUpdate, RecommendedSecurityUpdateId| sort by VulnerabilitySeverityLevel desc