Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2026-23136

Опубликовано: 14 фев. 2026
Источник: redhat
CVSS3: 7.6
EPSS Низкий

Описание

In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.

A flaw was found in the Linux kernel's libceph OSD client. When a connection fault occurs during a sparse read, the sparse-read state is not properly reset. This allows a misbehaving or compromised Ceph OSD server, or a network adversary, to disrupt traffic. As a result, the client can misinterpret new data as a continuation of previous data, leading to a persistent failure mode, repeated errors, and continuous retry loops, effectively causing a Denial of Service (DoS) for Ceph clients performing sparse reads.

Отчет

A reliability and availability issue exists in the libceph OSD client sparse read handling. The client tracks progress of a sparse read reply using a separate state machine. When a connection fault happens mid payload or when the sparse read state machine returns an error, the connection is abandoned and later reestablished and pending operations are retried. However the sparse read state was not reset on the fault path. As a result the client can misinterpret the beginning of a new reply as a continuation of the previous reply. This can drive the sparse read machinery into a persistent failure mode that may never recover, producing repeated error messages and repeated socket read failures, effectively preventing successful reads and causing continuous retry loops. From a threat perspective the trigger can be a misbehaving or compromised Ceph OSD server, or a network adversary able to disrupt or truncate traffic, causing fault and retry sequences. The primary impact is denial of service for Ceph clients performing sparse reads.

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Enterprise Linux 10kernelAffected
Red Hat Enterprise Linux 6kernelNot affected
Red Hat Enterprise Linux 7kernelNot affected
Red Hat Enterprise Linux 7kernel-rtNot affected
Red Hat Enterprise Linux 8kernelNot affected
Red Hat Enterprise Linux 8kernel-rtNot affected
Red Hat Enterprise Linux 9kernelAffected
Red Hat Enterprise Linux 9kernel-rtAffected

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-440
https://bugzilla.redhat.com/show_bug.cgi?id=2439852kernel: Linux kernel: Denial of Service in libceph OSD client due to unreset sparse-read state

EPSS

Процентиль: 3%
0.00015
Низкий

7.6 High

CVSS3

Связанные уязвимости

CVSS3: 5.5
ubuntu
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.

CVSS3: 5.5
nvd
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a cle

CVSS3: 5.5
debian
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: l ...

CVSS3: 5.5
github
около 1 месяца назад

In the Linux kernel, the following vulnerability has been resolved: libceph: reset sparse-read state in osd_fault() When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state. If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a ...

oracle-oval
17 дней назад

ELSA-2026-50144: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS

Процентиль: 3%
0.00015
Низкий

7.6 High

CVSS3