Linux Kernel EUVD-2026-66476

Exploitation requires the victim to run an in-kernel Ceph client (libceph) and to issue the cls_lock 'lock.get_info' class method - for example during RBD exclusive lock acquisition - against an OSD that the attacker controls or has compromised. The attacker needs only an established Ceph OSD session with no further privileges. Limiting factors: the target must actually use kernel RBD/CephFS (not userspace librbd), the attacker must be positioned as a trusted/reachable OSD in the deployment (most realistic in multi-tenant or shared clusters), and cephx authentication plus network isolation between tenants directly constrain who can present a malicious OSD reply.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H = 9.8) overstates real-world risk for two reasons. First, the primitive is a slab-out-of-bounds READ, which realistically yields kernel-memory disclosure and/or a crash (DoS) - the I:H and A:H claims (integrity impact especially) are not supported by the description, so an independent scoring lands closer to C:H/I:N/A:H. Second, and more importantly, exploitation is not against an arbitrary internet-facing service: it requires the victim kernel client to interact with a malicious or compromised OSD that the client already trusts and has established a session with. That is the 'evil server' trust-boundary model, credible mainly in multi-tenant or shared Ceph deployments, not opportunistic mass exploitation. There is no EPSS score, no KEV listing, and no POC in the supplied data - no public exploit identified at time of analysis. Net: patch it on Ceph/RBD-using kernel clients, but this is a targeted, deployment-specific issue rather than a wormable internet threat, and the 9.8 headline should not drive the same urgency as a truly unauthenticated-remote RCE.

In a multi-tenant Ceph cluster, an attacker who controls or compromises an OSD waits for a victim kernel client to perform RBD exclusive-lock acquisition, which triggers the lock.get_info call. The malicious OSD returns a crafted locker reply with struct_len=0 or len=0xffffffff, driving decode_locker() to read kernel slab memory far past the validated buffer, leaking data or crashing the client. No POC is present in the supplied data (no public exploit identified at time of analysis), and success needs only an established OSD session, no additional client-side privileges.