kernel security update

In der Linux-Kernel-Kern, der Betriebssystemkern selbst, wurden folgende Schwachstellen behoben:

erofs: Behebung des Inline-Daten-Leseversagens für ztailpacking pclusters

Komprimierte Folios für ztailpacking pclusters müssen vor dem Hinzufügen zu I/O-Ketten gültig sein. Andernfalls kann z_erofs_decompress_pcluster() annehmen, dass sie bereits gültig sind und dann eine Nullzeiger-Dereferenzierung auslösen.

Es ist etwas schwierig, dies zu reproduzieren, da die Inline-Daten im selben Block wie das Ende der komprimierten Indizes liegen, die normalerweise davor gelesen werden. Es kann jedoch immer noch passieren, wenn ein kritischer Signal während der Ausführung von read_mapping_folio() eintrifft, wie unten gezeigt:

erofs: (Gerät dm-1): z_erofs_pcluster_begin: Fehler beim Abrufen der Inline-Daten -4
Ungültige Behandlung der Nullzeiger-Dereferenzierung im Kernel bei der virtuellen Adresse 0000000000000008
...

Beheben Sie dies, indem Sie die Inline-Daten vor der Zuweisung und dem Hinzufügen der pclusters zu den I/O-Ketten lesen.

In der Linux-Kernel wurden folgende Schwachstellen behoben:

drm/amdgpu: Behebung eines Speicherlecks in amdgpu_acpi_enumerate_xcc()

In amdgpu_acpi_enumerate_xcc(), wenn amdgpu_acpi_dev_init() -ENOMEM zurückgibt, verlässt die Funktion direkt, ohne das zugewiesene xcc_info freizugeben, was zu einem Speicherleck führt.

Beheben Sie dies, indem Sie sicherstellen, dass xcc_info in den Fehlerpfaden korrekt freigegeben wird.

In der Linux-Kernel wurden folgende Schwachstellen behoben:

hwrng: Kern - Verwendung von RCU und work_struct zur Behebung einer Race-Condition

Aktuell wird hwrng_fill nicht gelöscht, bis der hwrng_fillfn()-Thread beendet wird. Da hwrng_unregister() hwrng_fill außerhalb des rng_mutex-Locks liest, kann ein gleichzeitiges hwrng_unregister() erneut kthread_stop() auf demselben Task aufrufen.

Zusätzlich, wenn hwrng_unregister() unmittelbar nach hwrng_register() aufgerufen wird, wurde der gestoppte Thread möglicherweise nie ausgeführt. Daher bleibt hwrng_fill auch nach dem Rückgabewert von hwrng_unregister() verschmutzt. In diesem Fall werden nachfolgende Aufrufe von hwrng_register() scheitern, neue Threads zu starten, und hwrng_unregister() wird kthread_stop() auf demselben freigegebenen Task aufrufen. In beiden Fällen tritt ein Use-After-Free auf:

refcount_t: Addition auf 0; Use-After-Free.
WARNUNG: ... bei lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0
Aufrufverfolgung:
 kthread_stop+0x181/0x360
 hwrng_unregister+0x288/0x380
 virtrng_remove+0xe3/0x200

Dieses Patch behebt die Race-Condition, indem der globale hwrng_fill-Pointer durch das rng_mutex-Lock geschützt wird, sodass der hwrng_fillfn()-Thread nur einmal gestoppt wird und Aufrufe von kthread_run() und kthread_stop() mit dem Lock gesichert werden.

Um ein Deadlock in hwrng_fillfn() zu vermeiden, während es mit dem Lock gestoppt wird, konvertieren wir current_rng in RCU, sodass get_current_rng() current_rng ohne das Lock lesen kann. Um das Lock aus put_rng() zu entfernen, verschieben wir die tatsächliche Bereinigung in eine work_struct.

Da get_current_rng() keine ERR_PTR-Werte mehr zurückgibt, werden die IS_ERR()-Überprüfungen von seinen Aufrufern entfernt.

Da hwrng_fill durch das rng_mutex-Lock geschützt ist, kann hwrng_fillfn() hwrng_fill nicht selbst löschen. Daher, wenn hwrng_fillfn() direkt nach dem Freigeben von current_rng zurückkehrt, würde kthread_stop() später auf einen freigegebenen task_struct aufgerufen werden. Um dies zu beheben, ruft hwrng_fillfn() jetzt schedule() auf, um die Aufgabe am Leben zu halten, bis sie gestoppt wird. Der Aufruf von kthread_stop() wird auch von hwrng_unregister() zu drop_current_rng() verschoben, um sicherzustellen, dass kthread_stop() auf allen möglichen Pfaden aufgerufen wird, auf denen current_rng NULL wird, sodass der Thread nicht ewig wartet.

In der Linux-Kernel wurden folgende Schwachstellen behoben:

bus: fsl-mc: Verwendung der generischen driver_override-Infrastruktur

Wenn ein Treiber über __driver_attach() geprüft wird, wird das match()-Callback des Busses ohne das Gerätelock aufgerufen, wodurch der driver_override-Feld ohne ein Lock zugegriffen wird, was zu einem Use-After-Free führen kann.

Beheben Sie dies, indem Sie die driver-core driver_override-Infrastruktur verwenden, die für die interne korrekte Sperre sorgt.

Es ist beabsichtigt, match() von __driver_attach() ohne das Gerätelock aufgerufen zu werden. [1]

In der Linux-Kernel wurden folgende Schwachstellen behoben:

vdpa: Verwendung der generischen driver_override-Infrastruktur

Wenn ein Treiber über __driver_attach() geprüft wird, wird das match()-Callback des Busses ohne das Gerätelock aufgerufen, wodurch der driver_override-Feld ohne ein Lock zugegriffen wird, was zu einem Use-After-Free führen kann.

Beheben Sie dies, indem Sie die driver-core driver_override-Infrastruktur verwenden, die für die interne korrekte Sperre sorgt.

Es ist beabsichtigt, match() von __driver_attach() ohne das Gerätelock aufgerufen zu werden. [1]

In der Linux-Kernel wurden folgende Schwachstellen behoben:

fs/mbcache: Stornieren der Shrink-Arbeit vor der Zerstörung des Caches

mb_cache_destroy() ruft shrinker_free() auf und löscht dann alle Cache-Einträge und den Cache selbst, storniert jedoch nicht zuerst die ausstehende c_shrink_work-Arbeit.

Wenn mb_cache_entry_create() c_shrink_work über schedule_work() plant und die Arbeit noch aussteht oder ausgeführt wird, wenn mb_cache_destroy() ausgeführt wird, wird mb_cache_shrink_worker() auf den Cache zugreifen, nachdem sein Speicher freigegeben wurde, was zu einem Use-After-Free führt.

Dies ist nur für einen privilegierten Benutzer (root oder CAP_SYS_ADMIN) erreichbar, der das letzte put eines eingebundenen ext2/ext4/ocfs2-Dateisystems auslösen kann.

Stornieren Sie die Arbeit mit cancel_work_sync() vor dem Aufruf von shrinker_free(), um sicherzustellen, dass der Arbeiter fertig ist und nicht neu geplant wird, bevor der Cache abgebaut wird.

In der Linux-Kernel wurden folgende Schwachstellen behoben:

drm/amd/display: Begrenzung der VBIOS-Rekordkettenspaziergänge

Alle Rekordkettenspaziergänge in bios_parser.c und bios_parser2.c verwenden for(;;) und beenden sich nur bei einem 0xFF Rekordtyp-Sentinel oder null Rekordgröße. Ein fehlerhaftes VBIOS-Bild ohne den Terminator-Rekord verursacht ungebundene Iterationen bei der Probedurchführung, potenziell Hunderttausende von Iterationen mit Rekordgröße=1. In den letzten Iterationen nahe der BIOS-Bildgrenze können auch Strukturaufzüge über die 2-Byte-Kopfzeile hinaus, die von GET_IMAGE validiert wird, aus dem Bereich lesen.

Begrenzen Sie alle 14 Rekordkettenspaziergänge auf 256 Iterationen (BIOS_MAX_NUM_RECORD). atombios.h definiert bis zu 22 verschiedene Rekordtypen und atomfirmware.h hat 13. Unter der Annahme von weniger als 10 Rekorden pro Typ (was vernünftig ist, da die meisten verbindungsbezogen sind) ist 256 eine großzügige obere Grenze.

(gepflückt aus dem Commit 95700a3d660287ed657d6892f7be9ffc0e294a93)

In der Linux-Kernel wurden folgende Schwachstellen behoben:

erof