CVE-2026-72135 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
tpm: TPM-Charaktergeräte als nicht suchbar (non-seekable) kennzeichnen
Die TPM-Charaktergeräte bieten eine sequenzielle Kommando/Antwort-Schnittstelle, doch ihre Open-Handler lassen FMODE_PREAD und FMODE_PWRITE aktiviert.
Nachdem ein Kommando eine Antwort ausstehend hinterlassen hat, übergibt pread(fd, buf, 16, 0x1400) den Wert 0x1400 als *off an tpm_common_read(). Die Übertragungslänge ist durch response_length begrenzt, der Offset wird jedoch bei der Bildung von data_buffer + *off unkontrolliert verwendet. Ein ausreichend großer Offset verursacht daher einen Out-of-Bounds-Heap-Lesezugriff über copy_to_user() und führt im Erfolgsfall des Kopiervorgangs zu einem Out-of-Bounds-Zero-Write durch das nachfolgende memset().
Positionales I/O bietet für diese Schnittstelle keine kohärenten Semantiken. Ein beliebiger pread-Offset kann nicht darstellen, wie viel von einer Antwort sequenziell verbraucht wurde. Der Write-Callback speichert stets ein Kommando am Anfang von data_buffer, während pwrite() file->f_pos nicht aktualisiert und den Cursor für das sequenzielle Lesen veralten lassen kann.
Rufen Sie nonseekable_open() aus beiden Open-Handlern auf. Dies entfernt FMODE_PREAD und FMODE_PWRITE, wodurch positionale Lese- und Schreibzugriffe mit -ESPIPE fehlschlagen, bevor die TPM-Callbacks erreicht werden, und kennzeichnet die Dateien explizit als nicht suchbar (non-seekable). Normales read() und write() verwenden weiterhin den bestehenden sequenziellen f_pos-Cursor, wodurch der Antwort-Zustandsautomat unverändert bleibt.
Getestet auf Linux 6.12 mit KASAN und einem swtpm TPM2-Gerät:
- Sequenzielle partielle Lesezugriffe gaben die vollständige Antwort zurück - pread() und preadv() mit Offset 0x1400 gaben -ESPIPE zurück - pwrite() und pwritev() mit Offset Null gaben -ESPIPE zurück - Die ausstehende Antwort blieb nach den abgelehnten Operationen intakt - Ein anschließender normaler Kommando/Antwort-Zyklus wurde ordnungsgemäß abgeschlossen - Es wurde kein KASAN-Bericht erzeugt.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.