CVE-2026-74261 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
ALSA: seq: Veraltete FIFO-Zellen während der Größenänderung vermeiden
snd_seq_fifo_resize() muss den Ersatz-Pool noch veröffentlichen, bevor es auf die FIFO-Nutzer wartet. Ein blockierendes snd_seq_read() hält f->use_lock, solange es schläft; daher müssen gleichzeitige Sender in der Lage sein, an den neuen Pool zu senden und diesen Leser statt eines Fehlers beim Schließen des alten Pools zu wecken.
Allerdings dupliziert snd_seq_fifo_event_in() ein Ereignis, bevor es f->lock übernimmt, und snd_seq_read() kann eine Zelle aus dem Dequeue nehmen und später snd_seq_fifo_cell_putback() aufrufen, wenn copy_to_user() oder snd_seq_expand_var_event() fehlschlägt. Wenn resize zwischenzeitlich f->pool austauscht und oldhead abkoppelt, kann entweder Pfad nach der Momentaufnahme eine Zelle des alten Pools wieder verknüpfen. Diese veraltete Zelle befindet sich außerhalb der geleerten oldhead-Liste, hält oldpool->counter erhöht und kann dazu führen, dass snd_seq_pool_delete() darauf wartet, dass der stillgelegte Pool abfließt.
Behalten Sie die bestehende Reihenfolge „Swap vor Wait“ in snd_seq_fifo_resize() bei, verwerfen Sie jedoch veraltete Zellen vor jeder FIFO-Wiederherverknüpfung. Überprüfen Sie Event-In-Zellen unter f->lock neu und versuchen Sie sie erneut gegen den veröffentlichten Ersatz-Pool; geben Sie stattdessen veraltete Putback-Zellen frei, anstatt sie wieder in die FIFO zu verknüpfen.
Das fehlerhafte Szenario umfasst zwei Pfade, wobei jede Spalte die Reihenfolge innerhalb dieses Pfades zeigt:
resize path: relink path: 1. Allocate newpool. 1. Take f->use_lock. 2. Swap f->pool to newpool and 2. Duplicate or dequeue an old-pool detach oldhead. cell before oldpool closes. 3. Mark oldpool closing and 3. Reach a later relink point after wait for FIFO users. resize published newpool. 4. Free oldhead and delete 4. Relink the old-pool cell after oldpool. resize detached oldhead. 5. Drop f->use_lock.
Der Reproducer meldet, dass ein Resize-ioctl im erwarteten Pool-Teardown-Pfad blockiert ist:
signal: resize iteration=98 target_pool=4 exceeded 250ms (elapsed=251ms) diagnostic: resize_tid=651 wchan=snd_seq_pool_done diagnostic: resize_tid=651 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Ein zweiter Lauf mit größeren Pools traf denselben Ziel-Pfad:
signal: resize iteration=32 target_pool=64 exceeded 250ms (elapsed=251ms) diagnostic: resize_tid=663 wchan=snd_seq_pool_done diagnostic: resize_tid=663 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.