"value":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: avoid online resizing failures due to oversized flex bg\n\nWhen we online resize an ext4 filesystem with a oversized flexbg_size,\n\n mkfs.ext4 -F -G 67108864 $dev -b 4096 100M\n mount $dev $dir\n resize2fs $dev 16G\n\nthe following WARN_ON is triggered:\n==================================================================\nWARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550\nModules linked in: sg(E)\nCPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314\nRIP: 0010:__alloc_pages+0x411/0x550\nCall Trace:\n <TASK>\n __kmalloc_large_node+0xa2/0x200\n __kmalloc+0x16e/0x290\n ext4_resize_fs+0x481/0xd80\n __ext4_ioctl+0x1616/0x1d90\n ext4_ioctl+0x12/0x20\n __x64_sys_ioctl+0xf0/0x150\n do_syscall_64+0x3b/0x90\n==================================================================\n\nThis is because flexbg_size is too large and the size of the new_group_data\narray to be allocated exceeds MAX_ORDER. Currently, the minimum value of\nMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding\nmaximum number of groups that can be allocated is:\n\n (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) \u2248 21845\n\nAnd the value that is down-aligned to the power of 2 is 16384. Therefore,\nthis value is defined as MAX_RESIZE_BG, and the number of groups added\neach time does not exceed this value during resizing, and is added multiple\ntimes to complete the online resizing. The difference is that the metadata\nin a flex_bg may be more dispersed."
"value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evita fallos de cambio de tama\u00f1o en l\u00ednea debido a flex bg sobredimensionado Cuando redimensionamos en l\u00ednea un sistema de archivos ext4 con un flexbg_size sobredimensionado, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G se activa el siguiente WARN_ON: ===================================== ============================== ADVERTENCIA: CPU: 0 PID: 427 en mm/page_alloc.c:4402 __alloc_pages+0x411/ 0x550 M\u00f3dulos vinculados en: sg(E) CPU: 0 PID: 427 Comm: resize2fs Contaminado: GE 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Seguimiento de llamadas: __kmalloc_large_node+0xa2/0x200 __kmalloc+ 0x16e/0x290 text4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 text4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ======== =============== ============================================ Esto se debe a que flexbg_size tambi\u00e9n lo es grande y el tama\u00f1o de la matriz new_group_data que se asignar\u00e1 excede MAX_ORDER. Actualmente, el valor m\u00ednimo de MAX_ORDER es 8, el valor m\u00ednimo de PAGE_SIZE es 4096, el n\u00famero m\u00e1ximo correspondiente de grupos que se pueden asignar es: (PAGE_SIZE << MAX_ORDER) / sizeof(struct text4_new_group_data) ? 21845 Y el valor que est\u00e1 hacia abajo -alineado a la potencia de 2 es 16384. Por lo tanto, este valor se define como MAX_RESIZE_BG, y el n\u00famero de grupos agregados cada vez no excede este valor durante el cambio de tama\u00f1o y se agrega varias veces para completar el cambio de tama\u00f1o en l\u00ednea. La diferencia es que los metadatos en flex_bg pueden estar m\u00e1s dispersos."