Answer in brief
CVE-2023-52636 records a High severity (CVSS 8.2) vulnerability in libceph: just wait for more data to be available on the socket. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 6.6 | Not reported |
| Linux/Linuxgeneric | >=d396f89db39a2f259e2125ca43b4c31bb65afcad <da9c33a70f095d5d55c36d0bfeba969e31de08ae || >=d396f89db39a2f259e2125ca43b4c31bb65afcad <bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8 || >=d396f89db39a2f259e2125ca43b4c31bb65afcad <8e46a2d068c92a905d01cbb018b00d66991585ab | da9c33a70f095d5d55c36d0bfeba969e31de08ae, bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8, 8e46a2d068c92a905d01cbb018b00d66991585ab |
Published upstream
Apr 2, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data(). The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let's reuse cursor->total_resid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. And then osd_sparse_read() could continue where it left off. [ idryomov: changelog ]
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2023-52636 records a High severity (CVSS 8.2) vulnerability in libceph: just wait for more data to be available on the socket. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 6.6 | Not reported |
| Linux/Linuxgeneric | >=d396f89db39a2f259e2125ca43b4c31bb65afcad <da9c33a70f095d5d55c36d0bfeba969e31de08ae || >=d396f89db39a2f259e2125ca43b4c31bb65afcad <bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8 || >=d396f89db39a2f259e2125ca43b4c31bb65afcad <8e46a2d068c92a905d01cbb018b00d66991585ab | da9c33a70f095d5d55c36d0bfeba969e31de08ae, bd9442e553ab8bf74b8be3b3c0a43bf4af4dc9b8, 8e46a2d068c92a905d01cbb018b00d66991585ab |
Published upstream
Apr 2, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: libceph: just wait for more data to be available on the socket A short read may occur while reading the message footer from the socket. Later, when the socket is ready for another read, the messenger invokes all read_partial_*() handlers, including read_partial_sparse_msg_data(). The expectation is that read_partial_sparse_msg_data() would bail, allowing the messenger to invoke read_partial() for the footer and pick up where it left off. However read_partial_sparse_msg_data() violates that and ends up calling into the state machine in the OSD client. The sparse-read state machine assumes that it's a new op and interprets some piece of the footer as the sparse-read header and returns bogus extents/data length, etc. To determine whether read_partial_sparse_msg_data() should bail, let's reuse cursor->total_resid. Because once it reaches to zero that means all the extents and data have been successfully received in last read, else it could break out when partially reading any of the extents and data. And then osd_sparse_read() could continue where it left off. [ idryomov: changelog ]
Quoted source text, attributed separately from HOL analysis.