Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/9p: corrige el valor uninit en p9_client_rpc() Syzbot con la ayuda de KMSAN informó el siguiente error: ERROR: KMSAN: valor uninit en trace_9p_client_res include/trace/events/ 9p.h:146 [en línea] ERROR: KMSAN: valor uninit en p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [en línea] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c: 122 Legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 montar fs/namespace.c:3692 [en línea] __do_sys_mount fs/namespace.c:3898 [en línea] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/ 0x1f0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit se creó en: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [en línea] alloc_pages_node include/linux/gfp.h:261 [en línea] página mm /slub.c:2175 [en línea] allocate_slab mm/slub.c:2338 [en línea] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c :3610 [en línea] __slab_alloc_node mm/slub.c:3663 [en línea] slab_alloc_node mm/slub.c:3835 [en línea] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [ en línea] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 1b9/0x28e0fs /9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 Legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/ 0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [en línea] __do_sys_mount fs/namespace.c:3898 [en línea] __se_sys_mount+0x725/0x810 fs/namespace .c: 3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c: 3875 do_syscall_64+0xd5/0x1f0 entry_syscall_64_after_hwframe+0x6d/0x75 if p9_check_errors () fails en p9_client no se inicialice correctamente. Sin embargo, trace_9p_client_res() termina intentando imprimirlo de todos modos antes de que finalice p9_client_rpc(). Solucione este problema asignando valores predeterminados a los campos p9_fcall como 'etiqueta' y (en caso de que KMSAN descubra algo nuevo) 'id' durante la etapa de asignación de etiquetas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: acpi: desvincular adaptadores mux antes de eliminar Hay un problema con la eliminación de la tabla de superposición ACPI específicamente relacionado con los multiplexores I2C. Considere una superposición ACPI SSDT que define un mux I2C PCA9548 en un bus I2C existente. Cuando se carga esta tabla, vemos la creación de un dispositivo para el chip PCA9548 general y 8 dispositivos más, un i2c_adapter cada uno para los canales mux. Todos estos están vinculados a sus equivalentes ACPI mediante una eventual invocación de acpi_bind_one(). Cuando descargamos la superposición SSDT nos encontramos con el problema. Los dispositivos ACPI se eliminan normalmente a través de acpi_device_del_work_fn() y acpi_device_del_list. Sin embargo, se genera la siguiente advertencia y seguimiento de la pila ya que la eliminación no se realiza correctamente: ------------[ cortar aquí ]------------ kernfs: no se puede elimine 'physical_node', sin directorio ADVERTENCIA: CPU: 1 PID: 11 en fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0 Módulos vinculados en: CPU: 1 PID: 11 Comm: kworker/u128:0 No contaminado 6.8 .0-rc6+ #1 Nombre de hardware: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 16/05/2023 Cola de trabajo: kacpi_hotplug acpi_device_del_work_fn RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0 Código: e4 00 48 89 ef e8 07 71db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000 RDX: 8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780 RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff R10: 00000000ffffbfff R11 : ffff8f000e0a0000 R12: ffff9f864008fb50 R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8 FS: 0000000000000000(0000) GS:ffff8f000e240000(0000) 00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0 Rastreo de llamadas: < TAREA> ? kernfs_remove_by_name_ns+0xb9/0xc0? __advertir+0x7c/0x130 ? kernfs_remove_by_name_ns+0xb9/0xc0? report_bug+0x171/0x1a0? handle_bug+0x3c/0x70? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? kernfs_remove_by_name_ns+0xb9/0xc0? kernfs_remove_by_name_ns+0xb9/0xc0 acpi_unbind_one+0x108/0x180 device_del+0x18b/0x490 ? srso_return_thunk+0x5/0x5f? srso_return_thunk+0x5/0x5f dispositivo_unregister+0xd/0x30 i2c_del_adapter.part.0+0x1bf/0x250 i2c_mux_del_adapters+0xa1/0xe0 i2c_device_remove+0x1e/0x80 dispositivo_release_driver_internal+0x19a/0x200 move_device+0xbf/0x100 dispositivo_del+0x157/0x490 ? __pfx_device_match_fwnode+0x10/0x10? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_acpi_notify+0x10f/0x140 notifier_call_chain+0x58/0xd0 blocking_notifier_call_chain+0x3a/0x60 acpi_device_del_work_fn+0x85/0x1d0 34/0x2f0 hilo_trabajador+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 ---[ end trace 0000000000000000 ]--- ... repetido 7 veces más, 1 por cada canal del mux ... El problema es que el enlace de los dispositivos ACPI a sus adaptadores I2C pares no se limpian correctamente. Profundizando en el problema, vemos que el orden de eliminación es tal que los dispositivos ACPI que coinciden con los adaptadores i2c del canal mux se eliminan primero durante la eliminación de la superposición SSDT. Para cada uno de los canales vemos una llamada a i2c_acpi_notify() con ACPI_RECONFIG_DEVICE_REMOVE pero, como estos dispositivos no son en realidad i2c_clients, no se hace nada por ellos. Más adelante, después de haber tratado cada uno de los canales mux, procedemos a eliminar el i2c_client que representa el dispositivo PCA9548. ---truncados---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: bcm: rpi: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") anotó el miembro hws de 'struct clk_hw_onecell_data' con __counted_by, que informa al sanitizante de los límites sobre la cantidad de elementos en hws, para que pueda advertir cuando se accede a hws fuera de los límites. Como se señaló en ese cambio, el miembro __counted_by debe inicializarse con la cantidad de elementos antes de que ocurra el primer acceso a la matriz; de lo contrario, habrá una advertencia de cada acceso antes de la inicialización porque la cantidad de elementos es cero. Esto ocurre en raspberrypi_discover_clocks() debido a que ->num se asigna después de que se haya accedido a ->hws: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 está fuera del rango para el tipo 'struct clk_hw *[] __counted_by(num)' (también conocido como 'struct clk_hw *[]') Mueva la inicialización ->num antes del primer acceso de ->hws, lo que borra la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: bcm: dvp: Assign ->num before accessing ->hws Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") anotó el miembro hws de 'struct clk_hw_onecell_data' con __counted_by, que informa al sanitizante de los límites sobre la cantidad de elementos en hws, para que pueda advertir cuando se accede a hws fuera de los límites. Como se señaló en ese cambio, el miembro __counted_by debe inicializarse con la cantidad de elementos antes de que ocurra el primer acceso a la matriz; de lo contrario, habrá una advertencia de cada acceso antes de la inicialización porque la cantidad de elementos es cero. Esto ocurre en clk_dvp_probe() debido a que ->num se asigna después de que se haya accedido a ->hws: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 El índice 0 está fuera del rango para el tipo 'struct clk_hw *[] __counted_by(num)' (también conocido como 'struct clk_hw *[]'). Mueva la inicialización ->num antes del primer acceso de ->hws, lo que borra la advertencia. .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: v4l: async: corrección de la entrada de la lista de notificadores init struct v4l2_async_notifier tiene varios miembros list_head, pero solo se inicializan la lista de espera y la lista de hechos. notifier_entry se mantuvo 'puesto a cero', lo que generó un list_head no inicializado. Esto da como resultado una desreferencia del puntero NULL si csi2_async_register() falla, por ejemplo, el nodo para el endpoint remoto está deshabilitado y devuelve -ENOTCONN. Las siguientes llamadas a v4l2_async_nf_unregister() dan como resultado una desreferencia del puntero NULL. Agregue el inicializador de encabezado de lista que falta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: 9p: agregar bloqueo faltante al tomar la lista de fid de dentry. Se corrigió un use-after-free en la lista de fid d_fsdata de dentry cuando un subproceso busca un fid a través de dentry mientras otro subproceso lo desvincula: UAF hilo: refcount_t: suma en 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 Linux /fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Liberado por: p9_fid_destroy (en línea) desconocido+0xb0 /0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 El problema es que no se accedió a d_fsdata bajo d_lock, porque normalmente d_release() solo se llama una vez que dentry no está disponible. ya no es accesible, pero como también lo llamamos explícitamente en v9fs_remove, ese bloqueo es necesario: mueva la hlist fuera del dentry bajo bloqueo y luego elimine la referencia de sus fids una vez que ya no sean accesibles.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/memory-failure: corrige el manejo de páginas disueltas pero no eliminadas de las páginas de amigos Cuando hice pruebas de falla de memoria recientemente, se produce el siguiente pánico: página: refcount:0 mapcount:0 mapeo :0000000000000000 índice:0x0 pfn:0x8cee00 banderas: 0x6fffe0000000000(nodo=1|zona=2|lastcpupid=0x7fff) raw: 06fffe0000000000 muerto000000000100 muerto000000000122 00000 00000000000 raw: 0000000000000000 00000000000000009 00000000ffffffff 0000000000000000 página volcada porque: VM_BUG_ON_PAGE(!PageBuddy(page)) -- ----------[ cortar aquí ]----------- ¡ERROR del kernel en include/linux/page-flags.h:1009! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__del_page_from_free_list+0x151/0x180 RSP: 0018:ffffa49c90437998 EFLAGS: 00000046 RAX: 0000000000000035 RBX: 0000009 RCX: ffff8dd8dfd1c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0 RBP: ffffd901233b8000 R08 : ffffffffab5511f8 R09: 0000000000008c69 R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80 R13: 0000000000000001 R14: ffff8dd8fffc0 c80 R15: 0000000000000009 FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 80050033 CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0 Seguimiento de llamadas: __rmqueue_pcplist+0x23b/0x520 get_page_from_freelist+0x26b/0xe40 __alloc_pages_noprof+0x113 /0x1120 __folio_alloc_noprof+0x11/0xb0 alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130 __alloc_fresh_hugetlb_folio+0xe7/0x140 alloc_pool_huge_folio +0x68/0x100 set_max_huge_pages+0x13d/0x340 hugetlb_sysctl_handler_common+0xe8/0x110 proc_sys_call_handler+0x194/0x280 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 +0xc2/0x1d0 entrada_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff916114887 RSP: 002b:00007ffec8a2fd78 EFLAGS : 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887 RDX: 0000000000000004 RSI: 000055eae500e39 0 RDI: 0000000000000003 RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0 R10: 0000000000000077 R11: 00000000000000246 R 12: 0000000000000004 R13: 00000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00 Módulos vinculados en: mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]--- Y antes del pánico, había una advertencia sobre el estado incorrecto de la página: ERROR: Estado incorrecto de la página en el proceso tipos de página pfn:8cee00 página: refcount:0 mapcount:0 mapeo:0000000000000000 índice:0x0 pfn:0x8cee00 banderas: 0x6fffe0000000000(nodo=1|zona=2|lastcpupid=0x7fff) tipo de página: 0xffffff7f(amigo) raw: 06fffe0000000000 241c0008 ffffd901240f8008 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000 página volcado porque: mapcount distinto de cero Módulos vinculados en: mce_inject hwpoison_inject CPU: 8 PID: 154211 Comm: tipos de página No contaminados 6.9.0-rc4-00499-g5544ec3178e2-dirty #22 Seguimiento de llamadas: dump_stack_lvl+0x83/0xa0 bad_page+ 0x63/0xf0 free_unref_page+0x36e/0x5c0 unpoison_memory+0x50b/0x630 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 /0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/ 0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f189a514887 RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffda RBX: 0000000000000000 RCX: 00007f189a514887 RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003 RBP: 00007ffdcd8997a0 0000000000000000 R09: 00007ffdcd8994b2 R10 : 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8 R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040 > La causa raíz debería ser la siguiente raza: Memory_failure try_memory_failure_hugetlb me_huge_page __page_handle_poison dissolve_free_hugetlb_folio Drain_all_pages ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: comprueba si hay un puntero de archivo que no sea NULL en io_file_can_poll(). En kernels anteriores, era posible activar una desreferencia del puntero NULL fuera de la ruta de preparación asincrónica forzada, si no se había creado ningún archivo. asignado. El rastro que conduce a esto tiene el siguiente aspecto: ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000b0 PGD 0 P4D 0 Ups: 0000 [#1] CPU SMP PREEMPT: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0 -rc3+ #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS desconocido 2/2/2022 RIP: 0010:io_buffer_select+0xc3/0x210 Código: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 84 21 01 00 00 4c 8b 20 5b RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246 RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 00000000000000040 RDX: 0000000000000000 RSI: 97aecfb04820 RDI: ffff97af234f1700 RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020 R10: ffffb7bec38c7dc8 R11: 000000000000 c000 R12: ffffb7bec38c7db8 R13: ffff97aecfb05800 R14 : ffff97aecfb05800 R15: ffff97af2be5e000 FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0 Seguimiento de llamadas: ? __die+0x1f/0x60 ? page_fault_oops+0x14d/0x420? do_user_addr_fault+0x61/0x6a0? exc_page_fault+0x6c/0x150? asm_exc_page_fault+0x22/0x30? io_buffer_select+0xc3/0x210 __io_import_iovec+0xb5/0x120 io_readv_prep_async+0x36/0x70 io_queue_sqe_fallback+0x20/0x260 io_submit_sqes+0x314/0x630 __do_sys_io_uring_enter+0x33 9/0xbc0 ? __do_sys_io_uring_register+0x11b/0xc50? vm_mmap_pgoff+0xce/0x160 do_syscall_64+0x5f/0x180 Entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x55e0a110a67e Código: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 0 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6 porque la solicitud está marcada como ASYNC forzado y tiene un archivo incorrecto fd y, por lo tanto, toma la ruta de preparación asincrónica forzada. Los kernels actuales con la preparación asíncrona de solicitud limpia ya no pueden solucionar este problema, pero para facilitar la compatibilidad, agreguemos esta verificación de seguridad aquí también, ya que realmente no hace daño. En ambos casos, esto inevitablemente terminará con un CQE publicado con -EBADF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: proteger folio::privado al adjuntar folios de búfer de extensión [ERROR] Desde la versión 6.8, varias personas reportan fallas raras del kernel, el factor común son mensajes de error de estado incorrecto de la página así: ERROR: Estado incorrecto de la página en el proceso kswapd0 pfn:d6e840 página: refcount:0 mapcount:0 mapeo:000000007512f4f2 index:0x2796c2c7c pfn:0xd6e840 aops:btree_aops ino:1 flags: 0x17ffffe0000008(uptodate|node=0|zone= 2 |lastcpupid=0x3fffff) tipo de página: 0xffffffff() raw: 0017ffffe0000008 dead000000000100 dead000000000122 ffff88826d0be4c0 raw: 00000002796c2c7c 0000000000000000 0000 0000ffffffff 0000000000000000 página volcada porque: mapeo no NULL [CAUSA] Commit 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() para asignar el método luego adjuntar ") cambia la secuencia al asignar un nuevo búfer de extensión. Anteriormente siempre llamábamos a grab_extent_buffer() en mapeo->i_private_lock, para garantizar la seguridad en la modificación en folio::private (que es un puntero al búfer de extensión para el tamaño de sector normal). Esto puede llevar a la siguiente ejecución: el subproceso A está intentando asignar un búfer de extensión en el bytenr X, con 4 páginas de 4K, mientras que el subproceso B está intentando liberar la página en X + 4K (la segunda página del búfer de extensión en X) . Hilo A | Hilo B -----------------------------------+------------ ------------------------- | btree_release_folio() | | Esto es para la página en X + 4K, | | No la página X. | | alloc_extent_buffer() | |- release_extent_buffer() |- filemap_add_folio() para el | | |- atomic_dec_and_test(eb->refs) | página en bytenr X (la primera | | | | página). | | | | Que devolvió -EEXIST. | | | | | | | |- filemap_lock_folio() | | | | Devolvió la primera página bloqueada. | | | | | | | |- grab_extent_buffer() | | | | |- atomic_inc_not_zero() | | | | | Devuelto falso | | | | |- folio_detach_private() | | |- folio_detach_private() para X | |- folio_test_private() | | |- folio_test_private() | Devuelto verdadero | | | Devuelto verdadero |- folio_put() | |- folio_put() Ahora hay dos opciones de venta en el mismo folio en el folio X, lo que provoca un recuento insuficiente del folio X y, finalmente, provoca el error BUG_ON() en la página->mapeo. La condición no es tan fácil de cumplir: - La publicación debe activarse para la página intermedia de un eb. Si la publicación está en la misma primera página de un eb, el bloqueo de página se activaría e impediría la ejecución. - folio_detach_private() tiene una ventana de ejecución muy pequeña. Es solo entre folio_test_private() y folio_clear_private(). Eso es exactamente cuando se usa mapeo->i_private_lock para evitar dicha ejecución, y la confirmación 09e6cef19c9f ("btrfs: refactor alloc_extent_buffer() para asignar-luego-adjuntar método") arruinó eso. En ese momento, pensé que el bloqueo de página se activaría ya que filemap_release_folio() también requiere que la página esté bloqueada, pero olvidé que filemap_release_folio() solo bloquea una página, no todas las páginas de un búfer de extensión. [FIX] Mueva todo el código que requiere i_private_lock a adjunto_eb_folio_to_filemap(), para que todo se haga con la protección de bloqueo adecuada. Además, para evitar problemas futuros, agregue un lockdep_assert_locked() adicional para garantizar que mantenemos el bloqueo adecuado. Para el reproductor que puede iniciar la ejecución (tarda unos minutos con el código instrumentado insertando retrasos en alloc_extent_buffer()): #!/bin/sh drop_caches () { while(true); hacer echo 3 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/compact_memory hecho } run_tar () { while(true); hacer para x en `seq 1 80`; hacer tar cf /dev/zero /mnt > /dev/null & hecho esperar hecho } mkfs.btrfs -f -d single -m single ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: genirq/irqdesc: Impide el use-after-free en irq_find_at_or_after() irq_find_at_or_after() elimina la referencia al descriptor de interrupción que devuelve mt_find() mientras no mantiene sparse_irq_lock ni el bloqueo de lectura de RCU, lo que significa que el descriptor se puede liberar entre mt_find() y la desreferencia: CPU0 CPU1 desc = mt_find() delay_free_desc(desc) irq_desc_get_irq(desc) KASAN informa el use-after-free: Rastreo de llamadas: irq_get_next_irq+0x58/0x84 show_stat+ 0x638/0x824 seq_read_iter+0x158/0x4ec proc_reg_read_iter+0x94/0x12c vfs_read+0x1e0/0x2c8 Liberado por la tarea 4471: slab_free_freelist_hook+0x174/0x1e0 __kmem_cache_free+0xa4/0x1dc x64/0x128 irq_kobj_release+0x28/0x3c kobject_put+0xcc/0x1e0 retardado_free_desc+ 0x14/0x2c rcu_do_batch+0x214/0x720 Protege el acceso con una sección de bloqueo de lectura de RCU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/ap: Se corrigió el fallo en la función interna del AP modificar_bitmap() Un fallo del sistema como este Dirección de error: 200000cb7df6f000 TEID: 200000cb7df6f403 Fallo en el modo de espacio de inicio al usar el kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Ups: 0038 ilc:3 [#1] Módulos SMP PREEMPT vinculados en: mlx5_ib... CPU: 8 PID: 7556 Comm: bash No contaminado 6.9.0-rc7 #8 Nombre de hardware: IBM 3931 A01 704 (LPAR) Krnl PSW: 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC :2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7 df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 K Código rnl: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 # 0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 l hola %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6, 0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Seguimiento de llamadas: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFORMACIÓN: lockdep está activado apagado. Última dirección del último evento de última hora: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Pánico del kernel: no se sincroniza: Excepción fatal: pánico_on_oops ocurrió cuando /sys/bus/ap/a[pq]mask se actualizó con un valor de máscara relativo (como +0x10-0x12,+60,-90) con uno de los valores numéricos que excede INT_MAX. La solución es simple: use valores largos sin signo para las variables internas. Las comprobaciones correctas ya están implementadas en la función, pero se usó un int simple para las variables internas con posibilidad de desbordamiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: soluciona la fuga de e_refcnt de mb_cache_entry en ext4_xattr_block_cache_find() Syzbot informa una advertencia de la siguiente manera: ======================= ======================= ADVERTENCIA: CPU: 0 PID: 5075 en fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Módulos vinculados en: CPU: 0 PID: 5075 Comm: syz-executor199 No contaminado 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Seguimiento de llamadas: ext4_put_super+0x6d4/0xcd0 fs/ext4/super .c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] === ========================================= Esto se debe a que al encontrar una entrada en ext4_xattr_block_cache_find (), si ext4_sb_bread() devuelve -ENOMEM, el e_refcnt del ce, que ya ha crecido en __entry_find(), no se guardará y, eventualmente, desencadenará el problema anterior en mb_cache_destroy() debido a una fuga del recuento de referencias. Entonces llame a mb_cache_entry_put() en la rama de error -ENOMEM como solución rápida.