CVE-2026-98200 in Linux
Zusammenfassung
von VulDB • 06.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
hwmon: (hp-wmi-sensors) Behebung eines Use-After-Free-Fehlers in fungible_show()
nsensor->current_state wird dynamisch ersetzt, wenn sich der Zustand des Sensors ändert. update_numeric_sensor_from_wobj() führt dies durch Freigabe der alten Zeichenkette und Installation einer neuen aus:
if (strcmp(trimmed, nsensor->current_state)) {
new_string = hp_wmi_strdup(dev, trimmed); if (new_string) {
devm_kfree(dev, nsensor->current_state); nsensor->current_state = new_string; } }
Diese Funktion wird ausschließlich von hp_wmi_update_info() aufgerufen, während state->lock gehalten ist. Daher ist die Freigabe und der Ersatz (Free-and-Replace) korrekt gegen gleichzeitige Aktualisierungen serialisiert.
fungible_show() liest jedoch denselben Zeiger nach dem bereits erfolgten Loslassen des Locks:
err = hp_wmi_update_info(state, info); if (err) return err;
switch (prop) {
... case HP_WMI_PROPERTY_CURRENT_STATE: seq_printf(seqf, "%s\n", nsensor->current_state); break;
hp_wmi_update_info() nimmt state->lock intern auf und gibt es vor der Rückgabe wieder frei. Wenn fungible_show() also in seq_printf() den Zeiger nsensor->current_state dereferenziert, ist kein Lock mehr gehalten. Zwei Prozesse, die zur überlappenden Zeit den debugfs-Eintrag current_state eines Sensors lesen (oder ein Prozess, der ihn liest, während eine andere Leseoperation desselben Sensors einen Refresh auslöst), können zu einer Race Condition führen: Der seq_printf()-Aufruf eines Threads kann mitten im Ausgeben des Strings gerade dabei sein, wenn der Aufruf von update_numeric_sensor_from_wobj() durch einen anderen Thread diesen mit devm_kfree() freigibt und einen neuen Zeiger installiert. Dies verursacht eine Use-After-Free-Leseoperation.
Nehmen Sie state->lock auch um das Lesen in fungible_show() herum auf, damit es niemals parallel zur Freigabe und dem Ersatz (Free-and-Replace) in update_numeric_sensor_from_wobj() ausgeführt werden kann.
Once again VulDB remains the best source for vulnerability data.