Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: p54: evitar desbordamiento de búfer en p54_rx_eeprom_readback() Robert Morris informó: |Si un dispositivo USB malicioso se hace pasar por una interfaz wifi p54 de Intersil y genera un mensaje eeprom_readback con un eeprom->v1.len largo, p54_rx_eeprom_readback() copiará los datos del mensaje más allá del final de priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] El controlador establece eeprom->v{1,2}.len en p54_download_eeprom(). Se supone que el dispositivo debe proporcionar la misma longitud al controlador. Sin embargo, es posible (como se muestra en el informe) modificar el valor para que provoque un bloqueo o pánico debido a un desbordamiento. Este parche soluciona el problema añadiendo el tamaño al contexto común del dispositivo, de modo que p54_rx_eeprom_readback ya no depende de valores posiblemente manipulados. Dicho esto, también comprueba si el firmware alteró el valor y ya no los copia. La única pequeña ventaja es que, antes de que el controlador intente leer la EEPROM, necesita cargar un firmware. El firmware del proveedor tiene una licencia propietaria y, por ello, no está presente en la mayoría de las distribuciones por defecto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Reparar UAF cuando se busca kallsym después de ftrace deshabilitado El siguiente problema ocurre con un módulo con errores: ERROR: no se puede controlar el error de página para la dirección: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: fffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e El problema anterior puede ocurrir de la siguiente manera: (1) Agregar punto de seguimiento de kprobe; (2) insmod test.ko; (3) El módulo activa ftrace deshabilitado; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Activará UAF como test.ko ya eliminado; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... El problema es cuando un módulo activa un problema con ftrace y establece ftrace_disable. ftrace_disable se establece cuando se descubre una anomalía y para evitar más daños, ftrace detiene toda modificación de texto. El problema que ocurrió fue que ftrace_disable detiene más que solo la modificación de texto. Cuando se carga un módulo, también se pueden rastrear sus funciones de inicio. Dado que kallsyms elimina las funciones de inicio después de cargar un módulo, ftrace las guarda cuando el módulo se carga y se habilita el seguimiento de funciones. Esto permite que la salida del seguimiento de funciones muestre los nombres de las funciones de inicio en lugar de solo sus direcciones de memoria. Al eliminar un módulo, se llama a ftrace_release_mod() y, si ftrace_disable está configurado, simplemente regresa sin hacer nada más. El problema es que deja la lista de mods (mod_list) aún activa, y si se llama a kallsyms, este ejecutará este código y accederá a la memoria del módulo ya liberada, ya que devolverá: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Donde el "mod" ya no existe, lo que genera un error de UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: corrección de fuga de caché de operandos de ACPI en dswstate.c, confirmación de ACPICA 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732. Se detectó una fuga de caché de ACPI en el caso de terminación anticipada de ACPI y continuación del arranque. Cuando se produce una terminación anticipada debido a una tabla ACPI maliciosa, el kernel de Linux finaliza la función ACPI y continúa el proceso de arranque. Mientras el kernel finaliza la función ACPI, kmem_cache_destroy() informa de una fuga de caché de operandos de ACPI. El registro de arranque de la fuga de caché de operandos de ACPI es el siguiente: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continuar con el arranque y se omite el registro ... Analicé esta pérdida de memoria en detalle y encontré que la función acpi_ds_obj_stack_pop_and_delete() calculó mal la parte superior de la pila. La función acpi_ds_obj_stack_push() usa walk_state->operand_index para la posición inicial del top, pero la función acpi_ds_obj_stack_pop_and_delete() considera el índice 0. Por lo tanto, esto provoca una fuga de memoria de operandos de ACPI. Esta fuga de caché representa una amenaza para la seguridad, ya que un kernel antiguo (<= 4.9) muestra las ubicaciones de memoria de las funciones del kernel en el volcado de pila. Algunos usuarios maliciosos podrían usar esta información para neutralizar la ASLR del kernel. Creé un parche para corregir la fuga de caché de operandos de ACPI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: se corrigen las fugas de caché de ACPI parse y parseext. Confirmación de ACPICA 8829e70e1360c81e7a5a901b5d4f48330e021ea5. Soy Seunghun Han y trabajo para el Instituto de Investigación de Seguridad Nacional de Corea del Sur. He estado investigando sobre ACPI y he encontrado una fuga de caché en casos de aborto temprano de ACPI. El registro de arranque de la pérdida de caché ACPI es el siguiente: [0.352414] ACPI: _OSI(Dispositivo de módulo) añadido [0.353182] ACPI: _OSI(Dispositivo de procesador) añadido [0.353182] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.353182] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.356028] ACPI: No se puede iniciar el intérprete ACPI [0.356799] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.360215] kmem_cache_destroy Estado Acpi: La caché Slab todavía tiene objetos [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Rastreo de llamadas: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 Analicé esta fuga de memoria en detalle. Descubrí que las cachés "Acpi-State" y "Acpi-Parse" se fusionaron porque el tamaño de los objetos de la caché era el mismo que el de la caché slab. Finalmente, descubrí que las cachés "Acpi-Parse" y "Acpi-parse_ext" se filtraron mediante el indicador SLAB_NEVER_MERGE de la función kmem_cache_create(). El punto de fuga de caché ACPI real es el siguiente: [0.360101] ACPI: _OSI(Dispositivo de módulo) añadido [0.360101] ACPI: _OSI(Dispositivo de procesador) añadido [0.360101] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.361043] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.364016] ACPI: No se puede iniciar el intérprete ACPI [0.365061] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: La caché Slab aún tiene objetos [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Rastreo de llamadas: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: La caché Slab aún tiene objetos [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Rastreo de llamadas: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nodo de software: Se corrige una comprobación OOB en software_node_get_reference_args(). software_node_get_reference_args() busca obtener el elemento @index-ésimo, por lo que el valor de la propiedad requiere al menos '(index + 1) * sizeof(*ref)' bytes, pero esto no se puede garantizar con la comprobación OOB actual y puede causar OOB para una propiedad mal formada. Se corrige usando como comprobación OOB '((index + 1) * sizeof(*ref) > prop->length)'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar comprobaciones de integridad en ino y xnid. syzbot reportó un error de f2fs como el siguiente: INFORMACIÓN: La tarea syz-executor140:5308 se bloqueó durante más de 143 segundos. No contaminada. 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-executor140 estado:D pila:24016 pid:5308 tgid:5308 ppid:5306 indicadores_de_tarea:0x400140 indicadores:0x00000006 Rastreo de llamadas: context_switch kernel/sched/core.c:5378 [inline] __schedule+0x190e/0x4c90 kernel/sched/core.c:6765 __schedule_loop kernel/sched/core.c:6842 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6857 io_schedule+0x8d/0x110 kernel/sched/core.c:7690 folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317 __folio_lock mm/filemap.c:1664 [inline] folio_lock include/linux/pagemap.h:1163 [inline] __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917 pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87 find_get_page_flags include/linux/pagemap.h:842 [inline] f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776 __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463 read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306 lookup_all_xattrs fs/f2fs/xattr.c:355 [inline] f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533 __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179 f2fs_acl_create fs/f2fs/acl.c:375 [inline] f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418 f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539 f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666 f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765 f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808 f2fs_add_link fs/f2fs/f2fs.h:3616 [inline] f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766 vfs_mknod+0x36d/0x3b0 fs/namei.c:4191 unix_bind_bsd net/unix/af_unix.c:1286 [inline] unix_bind+0x563/0xe30 net/unix/af_unix.c:1379 __sys_bind_socket net/socket.c:1817 [inline] __sys_bind+0x1e4/0x290 net/socket.c:1848 __do_sys_bind net/socket.c:1853 [inline] __se_sys_bind net/socket.c:1851 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1851 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Volcamos y verificamos los metadatos del inodo dañado, muestra que su xattr_nid es el mismo que su i_ino. dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid [0x 3 : 3] Entonces, durante mknod en el directorio dañado, intenta obtener y bloquear la página del inodo dos veces, lo que da como resultado un bloqueo. - f2fs_mknod - f2fs_add_inline_entry - f2fs_get_inode_page --- bloquear la página de inodo del directorio - f2fs_init_acl - f2fs_acl_create(dir,..) - __f2fs_get_acl - f2fs_getxattr - lookup_all_xattrs - __get_node_page --- intentar bloquear la página de inodo del directorio Para solucionar esto, agreguemos una verificación de cordura en ino y xnid.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: fbnic: evita la doble liberación al no poder asignar DMA a FW msg. La semántica es que quien llama a fbnic_mbx_map_msg() conserva la propiedad del mensaje en caso de error. Todos los que llaman liberan la página correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura de memoria OOB en la prueba KUnit KASAN informó un acceso fuera de los límites - cs_dsp_mock_bin_add_name_or_info(), porque la longitud de la cadena de origen se redondeó al tamaño de asignación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/bpf: corrección del cálculo del tamaño del código JIT del trampolín BPF. arch_bpf_trampoline_size() proporciona el tamaño JIT del trampolín BPF antes de asignar el búfer para su procesamiento JIT. El número total de instrucciones emitidas para el código JIT del trampolín BPF depende de la ubicación de la imagen final. Por lo tanto, el tamaño obtenido con el paso ficticio en arch_bpf_trampoline_size() puede variar del tamaño real necesario en arch_prepare_bpf_trampoline(). Cuando las instrucciones contabilizadas en arch_bpf_trampoline_size() son menores que la cantidad de instrucciones emitidas durante la compilación JIT real del trampolín, se produce la siguiente advertencia: ADVERTENCIA: CPU: 8 PID: 204190 en arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc que es: /* Asegúrese de que la lógica de generación del trampolín no se desborde */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { Entonces, durante el pase ficticio, en lugar de proporcionar una ubicación de imagen arbitraria, tenga en cuenta la máxima cantidad de instrucciones posibles si y cuando exista una dependencia con la ubicación de la imagen para JIT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/nfs/read: corrige error de doble desbloqueo en nfs_return_empty_folio() En ocasiones, cuando se leía un archivo mientras otro cliente NFS lo estaba truncando, el kernel podía bloquearse porque se llamaba a folio_unlock() dos veces y la segunda llamada XOR devolvería el indicador `PG_locked`. La mayoría de las veces (dependiendo del momento del truncamiento), nadie nota el problema porque folio_unlock() se llama tres veces, lo que desactiva `PG_locked`: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio El problema es que nfs_read_add_folio() no debe desbloquear el folio si fscache está habilitado, y falta una comprobación nfs_netfs_folio_unlock() en nfs_return_empty_folio(). En raras ocasiones, esto genera una advertencia en netfs_read_collection(): ------------[ cortar aquí ]------------ R=0000031c: el folio 10 no está bloqueado ADVERTENCIA: CPU: 0 PID: 29 en fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Cola de trabajo: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Rastreo de llamadas: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0worker_thread+0x295/0x3a0 Sin embargo, la mayoría de las veces, los procesos simplemente se quedan atascados para siempre en folio_wait_bit_common(), esperando que `PG_locked` desaparezca, lo que nunca sucede porque nadie está realmente reteniendo el cerradura de folio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: se corrigieron los errores data-race y null-ptr-deref en jbd2_journal_dirty_metadata(). Dado que handle->h_transaction puede ser un puntero nulo, debemos modificarlo para que llame primero a is_handle_aborted(handle) antes de desreferenciarlo. La siguiente vulnerabilidad data-race se reportó en mi fuzzer: ======================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ======================================================================== Este problema se debe a la falta de la anotación de carrera de datos para jh->b_modified. Por lo tanto, es necesario agregarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_via: Forzar PIO para dispositivos ATAPI en VT6415/VT6330 El controlador tiene un error de hardware que puede bloquear el sistema al realizar DMA ATAPI sin dejar rastro de lo sucedido. Dependiendo del dispositivo conectado, también puede impedir que el sistema arranque. En este caso, el sistema se bloquea al leer el ATIP desde un medio óptico con cdrecord -vvv -atip en un _NEC DVD_RW ND-4571A 1-01 y un Optiarc DVD RW AD-7200A 1.06 conectados a un ASRock 990FX Extreme 4, corriendo en UDMA/33. El problema se puede reproducir ejecutando el mismo comando con una compilación cygwin de cdrecord en WinXP, aunque requiere más intentos para provocarlo. El bloqueo en ese caso también se resuelve forzando PIO. No parece que VIA haya producido ningún controlador para ese sistema operativo, por lo que no existe ninguna solución alternativa conocida. Los discos duros conectados al controlador no sufren ningún problema de DMA.