CVE-2026-68082 in Linux
Zusammenfassung
von VulDB • 08.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
libceph: Behebung von zwei unsicheren rohen Decodierungen in decode_lockers()
decode_lockers() in cls_lock_client.c enthält zwei bare Decode-Operationen (rohe Decodierungen), die es einem böswilligen oder kompromittierten OSD ermöglichen, slab-out-of-bounds-Lesezugriffe auszulösen:
1. ceph_decode_32(p) im num_lockers-Feld verfügt über keine vorangehende Bereichsprüfung (Bounds-Check). ceph_start_decoding() akzeptiert struct_len=0 als gültig -- die interne Funktion ceph_decode_need(p, end, 0, bad) schlägt immer fehl bzw. ist irrelevant, da sie bei Länge 0 nicht greift -- sodass ceph_start_decoding(), wenn ein OSD struct_len=0 sendet, mit Erfolg zurückkehrt und p == end gilt. Die unmittelbar folgende bare Operation ceph_decode_32(p) liest dann 4 Bytes über die validierte Puffergrenze hinaus. Der Müllwert wird direkt an kzalloc_objs() als Locker-Anzahl weitergegeben.
Die Schwesterfunktion decode_watchers() in osd_client.c verwendet bereits nach ihrem eigenen Aufruf von ceph_start_decoding() ceph_decode_32_safe(). decode_lockers() war die einzige Stelle, die die bare Variante verwendete.
2. ceph_decode_8(p) nach der decode_locker()-Schleife verfügt über keine vorangehende Bereichsprüfung (Bounds-Check). Wenn ein OSD num_lockers so konstruiert, dass die Schleife p genau bis zu end vorschiebt, liest die darauffolgende bare Operation ceph_decode_8(p) ein Byte über die validierte Puffergrenze hinaus. Das Ergebnis wird direkt an *type weitergegeben, das von Aufrufern als Lock-Typ-Diskriminator verwendet wird, was einem OSD-kontrollierten One-Byte-OOB-Lesezugriff mit direktem Einfluss auf das Lock-Typ-Feld entspricht.
Beide Probleme werden behoben, indem die bare Operationen durch ihre sicheren Varianten ersetzt werden: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers)
Die goto-Ziele unterscheiden sich absichtlich: err_inval: ist ein neues Label, das direkt -EINVAL zurückgibt. Es wird für den Pfad des Vorbelegungsfehlers verwendet, in dem *lockers noch nicht zugewiesen wurde und nicht an ceph_free_lockers() übergeben werden darf.
err_free_lockers: ist das bestehende Label. Es wird für den Pfad nach der Zuweisung bei Fehlschlag verwendet, in dem *lockers zugewiesen wurde und freigegeben werden muss.
ret wird vor ceph_decode_8_safe() auf -EINVAL gesetzt, damit err_free_lockers im Falle einer Bereichsverletzung den korrekten Fehlercode zurückgibt. Ohne dies würde err_free_lockers einen veralteten ret-Wert (0 aus der erfolgreichen decode_locker()-Schleife) zurückgeben und die Fehlermeldung stillschweigend verschlucken.
-EINVAL ist für beide Fehlerschwerpunkte korrekt. Die vom OSD empfangenen Daten sind strukturell fehlerhaft. -ENOMEM würde die Art des Fehlers gegenüber Aufrufern und Stable-Backportern bei der Triagierung von Fehlerpfaden falsch darstellen.
Angreifermodell: Ein böswilliges oder kompromittiertes OSD in einer Multi-Tenant-Ceph-Bereitstellung kann dies gegen jeden Kernel-Client auslösen, der die Klassenmethode lock.get_info aufruft (z. B. während des Erwerbs eines exklusiven RBD-Locks).
[ idryomov: Changelog gekürzt, Formatierung angepasst ]
If you want to get the best quality for vulnerability data then you always have to consider VulDB.