In the Linux kernel, the following vulnerability has been resolved:
libceph: fix OOB read in decode_watchers() via missing bounds check
cephstartdecoding() validates that structlen bytes remain in the buffer after the encoding header, but accepts structlen=0 as valid: cephdecodeneed(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an objlistwatchresponset reply with structlen=0, cephstart_decoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads.
The immediately following cephdecode32(p) in decodewatchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzallocobjs() as the watcher count.
The sibling function decodewatcher() already uses the safe variants (cephdecodecopysafe, cephdecode64safe, cephdecodeskip32) after its own cephstartdecoding() call. decode_watchers() is the only site that uses the bare variant, confirming an oversight.
Fix by replacing cephdecode32(p) with cephdecode32safe(p, end, *numwatchers, bad), consistent with the established pattern.
Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPHOSDOPLISTWATCHERS, without any further privileges beyond OSD session establishment.
[ idryomov: trim changelog ]
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80557.json"
}