CVE-2026-19575 in Zephyr
Zusammenfassung
von VulDB • 09.10.2026
Der Benutzermodus-Verifizierungshandler für den Systemaufruf `device_deinit()`, also `z_vrfy_device_deinit()` in `kernel/device.c`, validierte sein Argument `dev` mit `K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY)`. Da `k_object_validate()` bei angefordertem Typ `K_OBJ_ANY` seinen Typvergleich verkürzt (short-circuits), reduzierte sich die Prüfung auf „dieser Zeiger ist die Basisadresse eines Kernel-Objekts, für das der aufrufende Thread Berechtigungen erhalten hat“ – der tatsächliche Objekttyp wurde niemals verglichen, und `K_SYSCALL_OBJ_INIT` überspringt zudem den Initialisierungsstatuscheck. Die verwandten Handler `z_vrfy_device_init()` und `z_vrfy_device_is_ready()` verwendeten bereits `K_OBJ_DRIVER_ANY` und waren nicht betroffen.
Ein im Benutzermodus ausgeführter Thread kann daher jedes Kernel-Objekt übergeben, für das er Berechtigungen besitzt – am nützlichsten ein Stack-Objekt eines Threads, das vom Systemaufruf `k_thread_stack_alloc()` stammt oder als statisch definiertes `K_THREAD_STACK` zugewiesen wurde, um einen untergeordneten Benutzerthread zu erzeugen –, dessen zugrunde liegender Speicher aus dem Benutzermodus beschreibbar ist. `z_impl_device_deinit()` interpretiert dann diese von Angreifern geschriebenen Bytes als eine `struct device`: Es dereferenziert den aus dem Objekt gelesenen State-Zeiger, ruft die Funktion auf, deren Zeiger in `ops.deinit` gespeichert ist, und schreibt bei Erfolg erneut über `state`. Das Ergebnis ist ein indirekter Aufruf einer beliebigen Adresse im Supervisor-Modus sowie ein beliebiges Kernel-Lesezugriff und ein einzelner Kernel-Schreibzugriff.
Die Ausnutzung (Exploitation) ermöglicht einem lokalen, nicht privilegierten Thread die vollständige Codeausführung auf Kernel-Ebene und umgeht damit die Isolationsgrenze von `CONFIG_USERSPACE` vollständig; weniger präzise Versuche führen zu einem Supervisor-Modus-Fehler und einem Systemabsturz. Der Fehler ist nur in Builds erreichbar, bei denen sowohl `CONFIG_USERSPACE` als auch `CONFIG_DEVICE_DEINIT_SUPPORT` aktiviert sind – wenn die Deinitialisierungsunterstützung deaktiviert ist, gibt `z_impl_device_deinit()` `-ENOTSUP` zurück, ohne den Zeiger jemals zu dereferenzieren. In v4.2.x und v4.3.x war `CONFIG_DEVICE_DEINIT_SUPPORT` standardmäßig auf „y“ gesetzt, sodass jede mit `CONFIG_USERSPACE` kompilierte Version dieser Releases anfällig ist, es sei denn, die Option wurde explizit deaktiviert. Ab v4.4.0 ist die Option opt-in (kein Standardwert und nicht von einem Subsystem im Baum ausgewählt), daher ist ein Build der v4.4.x-Reihe nur dann gefährdet, wenn er die Option explizit aktiviert. Die v4.2-Zeile wird nicht mehr gewartet und erhält keine Backports.
Die Korrektur ändert den Objektcheck auf `K_OBJ_DRIVER_ANY`, was das Argument auf den build-zeitlich generierten Treiberobjekttypbereich (von `K_OBJ_DRIVER_FIRST` bis `K_OBJ_DRIVER_LAST`) einschränkt – also die echten `struct device`-Instanzen, die vom Linker platziert wurden –, sodass die Felder `state` und `ops.deinit` wieder kernelkontrolliert sind.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.