CVE-2026-80557

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix OOB read in decode_watchers() via missing bounds check<br /> <br /> ceph_start_decoding() validates that struct_len bytes remain in the<br /> buffer after the encoding header, but accepts struct_len=0 as valid:<br /> ceph_decode_need(p, end, 0, bad) always passes. When a malicious or<br /> compromised OSD sends an obj_list_watch_response_t reply with<br /> struct_len=0, ceph_start_decoding() returns success with p == end,<br /> leaving zero bytes guaranteed for subsequent reads.<br /> <br /> The immediately following ceph_decode_32(p) in decode_watchers() has<br /> no preceding bounds check. With p == end this is a 4-byte read past<br /> the validated buffer boundary. The garbage value is then passed<br /> directly to kzalloc_objs() as the watcher count.<br /> <br /> The sibling function decode_watcher() already uses the safe variants<br /> (ceph_decode_copy_safe, ceph_decode_64_safe, ceph_decode_skip_32)<br /> after its own ceph_start_decoding() call. decode_watchers() is the<br /> only site that uses the bare variant, confirming an oversight.<br /> <br /> Fix by replacing ceph_decode_32(p) with ceph_decode_32_safe(p, end,<br /> *num_watchers, bad), consistent with the established pattern.<br /> <br /> Attacker model: a malicious or compromised OSD in a multi-tenant Ceph<br /> deployment (e.g. cloud) can trigger this against any kernel client<br /> that calls CEPH_OSD_OP_LIST_WATCHERS, without any further privileges<br /> beyond OSD session establishment.<br /> <br /> [ idryomov: trim changelog ]