Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: swap: corrige la ejecución entre free_swap_and_cache() y swapoff() Anteriormente existía una ventana teórica donde swapoff() podía ejecutar y desmantelar un swap_info_struct mientras se realizaba una llamada a free_swap_and_cache(). corriendo en otro hilo. Esto podría causar, entre otras malas posibilidades, que swap_page_trans_huge_swapped() (llamado por free_swap_and_cache()) acceda a la memoria liberada para swap_map. Este es un problema teórico y no he podido provocarlo a partir de un caso de prueba. Pero ha habido un acuerdo basado en la revisión del código de que esto es posible (ver enlace a continuación). Solucionarlo usando get_swap_device()/put_swap_device(), lo que detendrá swapoff(). Hubo una verificación adicional en _swap_info_get() para confirmar que la entrada de intercambio no era gratuita. Esto no está presente en get_swap_device() porque en general no tiene sentido debido a la ejecución entre obtener la referencia y el intercambio. Así que agregué una verificación equivalente directamente en free_swap_and_cache(). Detalles de cómo provocar un posible problema (gracias a David Hildenbrand por derivar esto): --8<----- __swap_entry_free() podría ser el último usuario y dar como resultado "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() se detendrá tan pronto como si->inuse_pages==0. Entonces la pregunta es: ¿alguien podría reclamar la publicación y activar si->inuse_pages==0, antes de que completemos swap_page_trans_huge_swapped()? Imagine lo siguiente: folio de 2 MiB en el swapcache. Sólo 2 subpáginas siguen siendo referencias mediante entradas de intercambio. El proceso 1 todavía hace referencia a la subpágina 0 mediante la entrada de intercambio. El proceso 2 todavía hace referencia a la subpágina 1 mediante la entrada de intercambio. El proceso 1 se cierra. Llama a free_swap_and_cache(). -> count == SWAP_HAS_CACHE [luego, adelantado en el hipervisor, etc.] El proceso 2 se cierra. Llama a free_swap_and_cache(). -> count == SWAP_HAS_CACHE El proceso 2 continúa, pasa swap_page_trans_huge_swapped() y llama a __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); ¿Qué impide que el intercambio tenga éxito después de que el proceso 2 recuperó el caché de intercambio pero antes de que el proceso 1 terminara su llamada a swap_page_trans_huge_swapped()? --8<-----

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac802154: corrige la liberación de recursos de clave llsec en mac802154_llsec_key_del mac802154_llsec_key_del() puede liberar recursos de una clave directamente sin seguir las reglas de RCU para esperar antes del final de un período de gracia. Esto puede llevar a un use-after-free en caso de que llsec_lookup_key() esté recorriendo la lista de claves en paralelo con una eliminación de clave: refcount_t: suma en 0; use-after-free. ADVERTENCIA: CPU: 4 PID: 16000 en lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Módulos vinculados en: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Nombre de hardware: PC estándar QEMU ( i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Seguimiento de llamadas: llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_ cifrar+ 0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __ sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Además, Las estructuras ieee802154_llsec_key_entry no son liberadas por mac802154_llsec_key_del(): objeto sin referencia 0xffff8880613b6980 (tamaño 64): comm "iwpan", pid 2176, jiffies 4294761134 (edad 60,475 s) volcado hexadecimal (primeros 32 bytes): 8 0d 8f 18 80 88 y siguientes y siguientes 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ........... ..... retroceso: [] __kmem_cache_alloc_node+0x1e2/0x2d0 [] kmalloc_trace+0x25/0xc0 [] mac802154_llsec_key_add+0xac9/0xcf0 ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [] nl802154_add_llsec_key+0x426/0x5b0 [] genl_family_rcv_msg_doit+0x1fe/0x2f0 [] genl_rcv_msg+0x531/0x7d0 [] netlink_rcv_skb+0x169/0x440 [] genl_rcv+0x28/0x40 [] netlink_unicast+0x53c/0x820 [] netlink_sendmsg+0x93b/0xe60 [] ____sys_sendmsg+0xac5/0xca0 [] ___sys_sendmsg+0x11d/0 x1c0 [] __sys_sendmsg+0xfa/0x1d0 [] do_syscall_64+0x45/0xf0 [] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Maneja la liberación adecuada de recursos en la función de devolución de llamada de RCU mac802154_llsec_key_del_rcu(). Tenga en cuenta que si llsec_lookup_key() encuentra una clave, obtiene un recuento a través de llsec_key_get() y copia localmente la identificación de la clave de key_entry (que es un elemento de la lista). Por lo tanto, es seguro llamar a llsec_key_put() y liberar la entrada de la lista después de que transcurra el período de gracia de RCU. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm-raid456, md/raid456: soluciona un punto muerto para dm-raid456 mientras io concurre con reshape. Para raid456, si el reshape todavía está en progreso, entonces IO en la posición de reshape esperará remodelar para progresar. Sin embargo, para dm-raid, en los siguientes casos la remodelación nunca progresará, por lo que IO se bloqueará: 1) la matriz es de solo lectura; 2) MD_RECOVERY_WAIT está configurado; 3) MD_RECOVERY_FROZEN está configurado; Después de confirmar c467e97f079f ("md/raid6: use valores de sector válidos para determinar si una E/S debe esperar a la remodelación") solucione el problema de que IO en la posición de remodelación no espera a la remodelación, la prueba dm-raid shell/lvconvert -raid-reshape.sh comienza a colgarse: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0 >] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [ <0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [ <0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [ <0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [ <0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] Entry_SYSCALL_64_after_hwframe+0x6c/0x74 Esto se debe a que la remodelación no puede progresar. Para md/raid, el problema no existe porque registrar un nuevo sync_thread ya no depende de que se realice la IO: 1) Si la matriz es de solo lectura, puede cambiar a lectura-escritura mediante ioctl/sysfs; 2) md/raid nunca configuró MD_RECOVERY_WAIT; 3) Si se configura MD_RECOVERY_FROZEN, mddev_suspend() no contiene 'reconfig_mutex', por lo tanto, se puede borrar y la remodelación puede continuar mediante sysfs api 'sync_action'. Sin embargo, todavía no estoy seguro de cómo evitar el problema en dm-raid. Este parche, por un lado, garantiza que raid_message() no pueda cambiar sync_thread() a través de raid_message() después de presuspend(), por otro lado detecta los 3 casos anteriores antes de esperar a que IO se realice en dm_suspend(), y deja dm-raid pone en cola esas IO.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-am62: corrige el comportamiento de descarga/recarga del módulo. Como el PM en tiempo de ejecución está habilitado, el tiempo de ejecución del módulo se puede suspender cuando se llama a .remove(). Realice pm_runtime_get_sync() para asegurarse de que el módulo esté activo antes de realizar cualquier operación de registro. Hacer pm_runtime_put_sync() debería deshabilitar refclk, por lo que no es necesario deshabilitarlo nuevamente. Corrige la siguiente advertencia al eliminar el módulo. [39.705310] ------------[ cortar aquí ]------------ [ 39.710004] clk:162:3 ya deshabilitado [ 39.713941] ADVERTENCIA: CPU: 0 PID : 921 en drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 Llamamos a of_platform_populate() en .probe(), así que llame a la función de limpieza of_platform_depopulate() en .remove(). Deshágase del ahora innecesario dwc3_ti_remove_core(). Sin esto, la recarga del módulo no funciona correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: xhci: agregar manejo de errores en xhci_map_urb_for_dma Actualmente, xhci_map_urb_for_dma() crea un búfer temporal y copia la lista SG en el nuevo búfer lineal. Pero si kzalloc_node() falla, entonces el siguiente sg_pcopy_to_buffer() puede provocar un fallo ya que intenta memcpy al puntero NULL. Entonces devuelve -ENOMEM si kzalloc devuelve un puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-apq8084: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: mmcc-msm8974: corrección de terminación de matrices de tablas de frecuencia Se supone que las matrices de tablas de frecuencia terminan con un elemento vacío. Agregue dicha entrada al final de las matrices donde falta para evitar un posible acceso fuera de los límites cuando la tabla es atravesada por funciones como qcom_find_freq() o qcom_find_freq_floor(). Solo compilar probado.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wireguard: netlink: acceda al dispositivo a través de ctx en lugar de peer. el commit anterior solucionó un error que provocaba que se desreferenciara un dispositivo NULL peer->. En realidad, es más fácil y rápido en cuanto a rendimiento obtener el dispositivo desde ctx->wg. Esto también tiene más sentido semánticamente, ya que ctx->wg->peer_allowedips.seq se compara con ctx->allowedips_seq, basándose ambos en ctx. Esto también actúa como una defensa en profundidad contra los pares liberados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: esp: corrige el mal manejo de las páginas desde page_pool Cuando el skb se reorganiza durante esp_output (!esp->inline), se supone que las páginas provenientes de los fragmentos del skb original son devuelto al sistema a través de put_page. Pero si las páginas del fragmento skb se originan en un page_pool, llamar a put_page en ellas desencadenará una fuga de page_pool que eventualmente resultará en un bloqueo. Esta fuga se puede observar fácilmente cuando se usa CONFIG_DEBUG_VM y se realiza el reenvío ipsec + gre (no descargado): ERROR: Estado de página incorrecto en el proceso ksoftirqd/16 pfn:1451b6 página:00000000de2b8d32 refcount:0 mapcount:0 mapeo:0000000000000000 índice:0x1451b6000 pfn: 0x1451b6 banderas: 0x200000000000000(nodo=0|zona=2) tipo de página: 0xffffffff() sin formato: 0200000000000000 muerto000000000040 ffff88810d23c000 0000000000000000 sin formato: 0001451b6000 0000000000000001 00000000ffffffff 0000000000000000 página volcada porque: fuga de page_pool Módulos vinculados en: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [última descarga: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 No contaminado 6 .8.0-rc4+ #22 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validar_xmit_xfrm+0x313/0x370 ? validar_xmit_skb+0x1d/0x330 validar_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 encuesta+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 La solución sugerida es introducir un nuevo contenedor (skb_page_unref) que cubra también el recuento de páginas para las páginas page_pool.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/zcrypt: corrige el recuento de referencias en los objetos de la tarjeta zcrypt. Las pruebas con tarjetas crypto de conexión en caliente en invitados KVM con compilación del kernel de depuración revelaron un use after free el campo de carga de la estructura zcrypt_card . El motivo fue un manejo de referencia incorrecto del objeto de la tarjeta zcrypt que podría provocar la liberación del objeto de la tarjeta zcrypt mientras aún estaba en uso. Este es un ejemplo del mensaje de losa: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. Primer byte 0x68 en lugar de 0x6b kernel: Asignado en zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/ 0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: Actually_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_ adjuntar+0x114/0x198 kernel: bus_probe_device+ Kernel 0xb4/0xc8: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: Process_one_work+0x26e/0x620 kernel: Kernel x21c/0x440: liberado en zcrypt_card_put +0x54/0x80 [zcrypt] edad=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device +0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: Núcleo 26e/0x620: trabajador_thread+ Kernel 0x21c/0x440: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objetos=20 usados=18 fp=0x00000000885a7c88 3ffff00000000a00(conjunto de trabajo|losa|nodo=0|zona =1|lastcpupid=0x1ffff) kernel: Objeto 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Objeto 00000000885a74 b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Objeto 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkk kkkkkkkk kernel: Objeto 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkk kernel: Objeto 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkk kernel: Objeto 000000 00885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel : Objeto 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd -udevd Not tainted 6.8.0-HF #2 kernel: Nombre del hardware: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report +0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] +0x1ee/0x3e0 núcleo: [<00000000c99d94ec> ] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0 ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [< 00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wireguard: netlink: verifique si hay pares pendientes a través de is_dead en lugar de una lista vacía. Si todos los pares se eliminan a través de wg_peer_remove_all(), en lugar de configurar peer_list como vacío, el par se agrega a una lista temporal. lista con un encabezado en la pila de wg_peer_remove_all(). Si se reanuda un volcado de netlink y el par seleccionado es uno que se eliminó mediante wg_peer_remove_all(), iterará desde ese par y luego intentará volcar los pares liberados. Para solucionar este problema, marque peer->is_dead, que se creó explícitamente para este propósito. También suba la aserción de bloqueo de dispositivo_update_lock, ya que la lectura is_dead depende de eso. Se puede reproducir mediante un pequeño script como: echo "Configuración de configuración..." ip link add dev wg0 tipo wireguard wg setconf wg0 /big-config (mientras sea verdadero; haga echo "Mostrando configuración..." wg showconf wg0 > / dev/null done) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resultando en: ERROR: KASAN: slab-use-after-free en __lock_acquire+0x182a/0x1b20 Lectura de tamaño 8 en la dirección ffff88811956ec70 mediante la tarea wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Seguimiento de llamadas: dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c /0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige el error al detectar daños en DAT en btree y asignaciones directas Serie de parches "nilfs2: corrige el error del kernel en submit_bh_wbc()". Esto resuelve un ERROR del kernel informado por syzbot. Dado que hay dos fallas involucradas, hice un parche para cada uno por separado. El primer parche por sí solo resuelve el error reportado por syzbot, pero creo que ambas correcciones deberían enviarse a estable, así que las etiqueté como tales. Este parche (de 2): Syzbot ha informado de un error en el kernel en submit_bh_wbc() al escribir datos de archivos en un sistema de archivos nilfs2 cuyos metadatos están dañados. Hay dos errores involucrados en este tema. El primer defecto es que cuando nilfs_get_block() localiza un bloque de datos usando btree o mapeo directo, si la rutina de traducción de direcciones de disco nilfs_dat_translate() falla con el código interno -ENOENT debido a la corrupción de los metadatos DAT, se puede devolver a nilfs_get_block(). Esto hace que nilfs_get_block() identifique erróneamente un bloque existente como inexistente, lo que provoca que tanto la búsqueda como la inserción del bloque de datos fallen de manera inconsistente. El segundo defecto es que nilfs_get_block() devuelve un estado exitoso en este estado inconsistente. Esto hace que la persona que llama __block_write_begin_int() u otros soliciten una lectura aunque el búfer no esté asignado, lo que resulta en una verificación BUG_ON para el indicador BH_Mapped en submit_bh_wbc() que falla. Esto soluciona el primer problema cambiando el valor de retorno al código -EINVAL cuando falla una conversión usando DAT con el código -ENOENT, evitando la condición conflictiva que conduce al error del kernel descrito anteriormente. Aquí, el código -EINVAL indica que se detectó corrupción de metadatos durante la búsqueda del bloque, lo que se manejará adecuadamente como un error del sistema de archivos y se convertirá a -EIO al pasar a través de la capa bmap nilfs2.