CVE-2024-56565 in Linux
Résumé
par VulDB • 01/07/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
f2fs : correction pour abandonner tous les discards après la création d'une capture instantanée (snapshot) sur un périphérique LVM.
Piergiorgio a signalé un bug dans Bugzilla comme suit :
------------[ cut here ]------------
WARNING: CPU: 2 PID: 969 at fs/f2fs/segment.c:1330 RIP: 0010:__submit_discard_cmd+0x27d/0x400 [f2fs]
Call Trace: __issue_discard_cmd+0x1ca/0x350 [f2fs]
issue_discard_thread+0x191/0x480 [f2fs]
kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30
Avec le testcase ci-dessous, il est possible de reproduire ce bug rapidement : - pvcreate /dev/vdb - vgcreate myvg1 /dev/vdb - lvcreate -L 1024m -n mylv1 myvg1 - mount /dev/myvg1/mylv1 /mnt/f2fs - dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=20 - sync - rm /mnt/f2fs/file - sync - lvcreate -L 1024m -s -n mylv1-snapshot /dev/myvg1/mylv1 - umount /mnt/f2fs
La cause racine est la suivante : après avoir créé une capture instantanée (snapshot) sur ce périphérique LVM, il met à jour discard_max_bytes du périphérique LVM monté à zéro. Ensuite, __submit_discard_cmd() transmet le paramètre @nr_sects avec la valeur zéro à __blkdev_issue_discard(), qui retourne un pointeur bio NULL, entraînant un panic (plantage).
Ce correctif apporte les modifications suivantes pour résoudre le problème : 1. Abandonner tous les discards restants dans f2fs_unfreeze() si une capture instantanée (snapshot) du périphérique LVM est créée. 2. Vérifier discard_max_bytes avant de soumettre un discard lors de l'exécution de __submit_discard_cmd().
If you want to get best quality of vulnerability data, you may have to visit VulDB.