CVE-2023-54023 in Linux
Riassunto
di VulDB • 16/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
btrfs: correzione di una race condition tra l'operazione di bilanciamento (balance) e le operazioni di annullamento/pausa
Syzbot ha segnalato un panic con il seguente aspetto:
assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------
kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: <TASK> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline]
btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline]
btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Il programma di test (reproducer) esegue in parallelo un'operazione di bilanciamento e una di annullamento o pausa. Il meccanismo con cui il bilanciamento termina è piuttosto complesso; se siamo in stato di pausa, è necessario salvare l'oggetto balance_ctl all'interno di fs_info, ma svuotarlo negli altri casi per procedere alla pulizia (cleanup). Tuttavia, ci si affida al fatto che i valori restituiti siano errori specifici o che sia presente una richiesta di annullamento oppure nessuna richiesta di pausa. Se il bilanciamento viene completato e restituisce 0, ma è presente una richiesta di pausa o annullamento, non verrà eseguita la corretta pulizia; di conseguenza, al successivo tentativo di avvio del bilanciamento si verificherà questo ASSERT (asserzione).
La gestione degli errori in questa sezione è errata: è sempre necessario eseguire la pulizia, a meno che non sia stato ricevuto -ECANCELLED e non sia stata impostata l'apposita flag di pausa nell'operazione esclusiva. Con questa patch, il programma di test ha eseguito per un'ora senza causare crash; precedentemente si verificava un errore in meno di pochi minuti.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.