CVE-2025-40128

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix symbolic link reading when bs &gt; ps<br /> <br /> [BUG DURING BS &gt; PS TEST]<br /> When running the following script on a btrfs whose block size is larger<br /> than page size, e.g. 8K block size and 4K page size, it will trigger a<br /> kernel BUG:<br /> <br /> # mkfs.btrfs -s 8k $dev<br /> # mount $dev $mnt<br /> # mkdir $mnt/dir<br /> # ln -s dir $mnt/link<br /> # ls $mnt/link<br /> <br /> The call trace looks like this:<br /> <br /> BTRFS warning (device dm-2): support for block size 8192 with page size 4096 is experimental, some features may be missing<br /> BTRFS info (device dm-2): checking UUID tree<br /> BTRFS info (device dm-2): enabling ssd optimizations<br /> BTRFS info (device dm-2): enabling free space tree<br /> ------------[ cut here ]------------<br /> kernel BUG at /home/adam/linux/include/linux/highmem.h:275!<br /> Oops: invalid opcode: 0000 [#1] SMP<br /> CPU: 8 UID: 0 PID: 667 Comm: ls Tainted: G OE 6.17.0-rc4-custom+ #283 PREEMPT(full)<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022<br /> RIP: 0010:zero_user_segments.constprop.0+0xdc/0xe0 [btrfs]<br /> Call Trace:<br /> <br /> btrfs_get_extent.cold+0x85/0x101 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f]<br /> btrfs_do_readpage+0x244/0x750 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f]<br /> btrfs_read_folio+0x9c/0x100 [btrfs 7453c70c03e631c8d8bfdd4264fa62d3e238da6f]<br /> filemap_read_folio+0x37/0xe0<br /> do_read_cache_folio+0x94/0x3e0<br /> __page_get_link.isra.0+0x20/0x90<br /> page_get_link+0x16/0x40<br /> step_into+0x69b/0x830<br /> path_lookupat+0xa7/0x170<br /> filename_lookup+0xf7/0x200<br /> ? set_ptes.isra.0+0x36/0x70<br /> vfs_statx+0x7a/0x160<br /> do_statx+0x63/0xa0<br /> __x64_sys_statx+0x90/0xe0<br /> do_syscall_64+0x82/0xae0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> <br /> Please note bs &gt; ps support is still under development and the<br /> enablement patch is not even in btrfs development branch.<br /> <br /> [CAUSE]<br /> Btrfs reuses its data folio read path to handle symbolic links, as the<br /> symbolic link target is stored as an inline data extent.<br /> <br /> But for newly created inodes, btrfs only set the minimal order if the<br /> target inode is a regular file.<br /> <br /> Thus for above newly created symbolic link, it doesn&amp;#39;t properly respect<br /> the minimal folio order, and triggered the above crash.<br /> <br /> [FIX]<br /> Call btrfs_set_inode_mapping_order() unconditionally inside<br /> btrfs_create_new_inode().<br /> <br /> For symbolic links this will fix the crash as now the folio will meet<br /> the minimal order.<br /> <br /> For regular files this brings no change.<br /> <br /> For directory/bdev/char and all the other types of inodes, they won&amp;#39;t<br /> go through the data read path, thus no effect either.