CVE-2024-49958

In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.

CVSS

No CVSS.

References

Link	Resource
https://git.kernel.org/stable/c/020f5c53c17f66c0a8f2d37dad27ace301b8d8a1
https://git.kernel.org/stable/c/5c2072f02c0d75802ec28ec703b7d43a0dd008b5
https://git.kernel.org/stable/c/5ca60b86f57a4d9648f68418a725b3a7de2816b0
https://git.kernel.org/stable/c/637c00e06564a945e9d0edb3d78d362d64935f9f
https://git.kernel.org/stable/c/96ce4c3537114d1698be635f5e36c62dc49df7a4
https://git.kernel.org/stable/c/9f9a8f3ac65b4147f1a7b6c05fad5192c0e3c3d9
https://git.kernel.org/stable/c/aac31d654a0a31cb0d2fa36ae694f4e164a52707

Configurations

No configuration.

History

23 Oct 2024, 15:13

Type	Values Removed	Values Added
Summary		(es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: reserva espacio para xattr en línea antes de adjuntar árbol reflink Uno de nuestros clientes informó de un fallo y un sistema de archivos ocfs2 dañado. El fallo se debió a la detección de una corrupción. Tras la resolución de problemas, la salida de fsck -fn mostró la siguiente corrupción [EXTENT_LIST_FREE] La lista de extensiones del propietario 33080590 afirma que 230 es el siguiente registro de cadena libre, pero fsck cree que el valor válido más grande es 227. ¿Fijar el siguiente valor de registro? n La salida de estadísticas de debugfs.ocfs2 mostró la siguiente corrupción, donde "Next Free Rec:" había superado "Count:" en el bloque de metadatos raíz. Inodo: 33080590 Modo: 0640 Generación: 2619713622 (0x9c25a856) Generación FS: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Tipo: Regular Atributo: 0x0 Indicadores: Válido Características dinámicas: (0x16) HasXattr InlineXattr Refcounted Bloque de atributos extendidos: 0 Tamaño en línea de atributos extendidos: 256 Usuario: 0 (raíz) Grupo: 0 (raíz) Tamaño: 281320357888 Enlaces: 1 Clústeres: 141738 ctime: 0x66911b56 0x316edcb8 -- Vie Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Vie Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Vie Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Mié Dic 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... ....... ....... El problema estaba en el flujo de trabajo de reflink mientras se reservaba espacio para xattr en línea. La función problemática es ocfs2_reflink_xattr_inline(). Para cuando se llama a esta función, el árbol de reflink ya se ha recreado en el inodo de destino a partir del inodo de origen. En este punto, esta función reserva espacio para xattrs en línea en el inodo de destino sin siquiera verificar si hay espacio en el bloque de metadatos raíz. Simplemente reduce el l_count de 243 a 227, lo que crea un espacio de 256 bytes para xattr en línea, mientras que el inodo ya tiene extensiones más allá de este índice (en este caso, hasta 230), lo que provoca corrupción. La solución para esto es reservar espacio para metadatos en línea en el inodo de destino antes de que se vuelva a crear el árbol de enlaces de referencia. El cliente ha verificado la solución.

21 Oct 2024, 18:15

Type	Values Removed	Values Added
New CVE

JSON object

Attach tags to CVE-2024-49958

Attach tags to `CVE-2024-49958`