CVE-2026-64593

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not trim a device which is not writeable<br /> <br /> [BUG]<br /> There is a bug report that btrfs/242 can randomly fail with the<br /> following NULL pointer dereference:<br /> <br /> run fstests btrfs/242 at 2026-06-01 10:25:08<br /> BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609)<br /> BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874<br /> BTRFS info (device sdc): using crc32c checksum algorithm<br /> BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing<br /> BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing<br /> BTRFS info (device sdc): allowing degraded mounts<br /> BTRFS info (device sdc): turning on async discard<br /> BTRFS info (device sdc): enabling free space tree<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000<br /> CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025<br /> pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_trim_fs+0x34c/0xa00 [btrfs]<br /> lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs]<br /> Call trace:<br /> btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P)<br /> btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]<br /> btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]<br /> __arm64_sys_ioctl+0xac/0x108<br /> invoke_syscall.constprop.0+0x5c/0xd0<br /> el0_svc_common.constprop.0+0x40/0xf0<br /> do_el0_svc+0x24/0x40<br /> el0_svc+0x40/0x1d0<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1b0/0x1b8<br /> Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Also the reporter is very kind to test the following ASSERT() added to<br /> btrfs_trim_free_extents_throttle():<br /> <br /> ASSERT(device-&gt;bdev,<br /> "devid=%llu path=%s dev_state=0x%lx\n",<br /> device-&gt;devid, btrfs_dev_name(device), device-&gt;dev_state);<br /> <br /> And it shows the following output:<br /> <br /> assertion failed: device-&gt;bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82)<br /> <br /> Which means the device-&gt;bdev is NULL, and the dev_state is<br /> BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without<br /> BTRFS_DEV_STATE_WRITEABLE flag set.<br /> <br /> [CAUSE]<br /> The pc points to the following call chain:<br /> <br /> btrfs_trim_fs()<br /> |- btrfs_trim_free_extents()<br /> |- btrfs_trim_free_extents_throttle()<br /> |- bdev_max_discard_sectors(device-&gt;bdev)<br /> <br /> So the NULL pointer dereference is caused by device-&gt;bdev being NULL.<br /> <br /> This looks impossible by a quick glance, as just before calling<br /> btrfs_trim_free_extents_throttle(), we have skipped any device that has<br /> BTRFS_DEV_STATE_MISSING flag set.<br /> <br /> However in this particular case, there is a window where the missing<br /> device is later re-scanned, causing btrfs to remove the<br /> BTRFS_DEV_STATE_MISSING flag:<br /> <br /> btrfs_control_ioctl()<br /> |- btrfs_scan_one_device()<br /> |- device_list_add()<br /> |- rcu_assign_pointer(device-&gt;name, name);<br /> | This updates the missing device&amp;#39;s path to the new good path.<br /> |<br /> |- clear_bit(BTRFS_DEV_STATE_MISSING, &amp;device-&gt;dev_state)<br /> This removes the BTRFS_DEV_STATE_MISSING flag.<br /> <br /> This allows the missing device to re-appear and clear the<br /> BTRFS_DEV_STATE_MISSING flag. However the device still does not have<br /> the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated.<br /> <br /> The bdev pointer remains NULL, triggering the crash later.<br /> <br /> [FIX]<br /> This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and<br /> device-&gt;bdev pointer, and shows a gap in btrfs&amp;#39;s re-appearing-device<br /> handling.<br /> <br /> The proper handling of re-appearing device will need quite some extra<br /> work, which is out of the context of this small<br /> ---truncated---