Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: no generar ERRORES si alguien ensucia páginas sin preguntar primero a ext4 [un]pin_user_pages_remote está ensuciando páginas sin advertir adecuadamente al sistema de archivos con anticipación. Jan Kara notó una ejecución relacionada en 2018[1]; sin embargo, más recientemente, en lugar de ser una ejecución muy difícil de alcanzar, podría ser activada de manera confiable por process_vm_writev(2) que fue descubierto por Syzbot[2]. Técnicamente, esto es un error en mm/gup.c, pero podría decirse que ext4 es frágil en el sentido de que si algún otro subsistema del kernel ensucia páginas sin notificar adecuadamente al sistema de archivos usando page_mkwrite(), ext4 generará ERRORES, mientras que otros sistemas de archivos no generarán ERRORES (aunque aún se perderán datos). Entonces, en lugar de bloquearse con un ERROR, emita una advertencia (ya que puede haber una posible pérdida de datos) y simplemente marque la página como limpia para evitar ataques de denegación de servicio sin privilegios hasta que el problema pueda solucionarse correctamente. Se puede encontrar más discusión y antecedentes en el hilo que comienza en [2]. [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: Se corrigen los fallos de vaciado de caché TLB de datos sin acceso Cuando una página no está presente, obtenemos fallos de TLB de datos sin acceso de las instrucciones fdc y fic en flush_user_dcache_range_asm y flush_user_icache_range_asm. Cuando esto ocurre, la línea de caché no se invalida y potencialmente obtenemos corrupción de memoria. El problema estaba oculto por la anulación de las instrucciones de vaciado. Estos fallos también afectan el rendimiento. Con los procesadores pa8800/pa8900, habrá 32 fallos por página de 4 KB ya que la línea de caché es de 128 bytes. Habrá más fallos con procesadores anteriores. El problema se soluciona utilizando flush_cache_pages(). Realiza el vaciado utilizando una asignación de alias tmp. La llamada flush_cache_pages() en flush_cache_range() vació un rango demasiado grande. V2: Eliminar las llamadas preempt_disable() y preempt_enable() innecesarias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: fsi: Implementar un tiempo de espera para sondear el estado Las rutinas de transferencia de datos deben sondear el registro de estado para determinar cuándo se pueden introducir o sacar más datos. Si el hardware entra en un mal estado, estos bucles de sondeo pueden no salir nunca. Evite esto devolviendo un error si se excede un tiempo de espera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: reparar ext4_mb_mark_bb() con flex_bg con fast_commit En el caso de la característica flex_bg (que está habilitada por defecto), las extensiones para cualquier inodo dado pueden abarcar bloques de dos grupos de bloques diferentes. ext4_mb_mark_bb() solo lee el buffer_head del mapa de bits del bloque una vez para el grupo de bloques de inicio, pero no puede leerlo de nuevo cuando el límite de longitud de la extensión se desborda a otro grupo de bloques. Luego, en este bucle a continuación, accede a la memoria más allá del mapa de bits del grupo de bloques buffer_head y da como resultado una interrupción de datos. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) Already++; Este parche agrega esta funcionalidad para verificar el límite del grupo de bloques en ext4_mb_mark_bb() y actualizar el buffer_head(bitmap_bh) para cada grupo de bloques diferente. Sin este parche, pude lograr fácilmente un aborto de acceso a datos usando la plataforma Power. <...> [ 74.327662] Error EXT4-fs (dispositivo loop3): ext4_mb_generate_buddy:1141: grupo 11, mapa de bits de bloque y descriptor de fondo inconsistentes: 21248 vs 23294 clústeres libres [ 74.533214] EXT4-fs (loop3): apagado solicitado (2) [ 74.536705] Abortando diario en dispositivo loop3-8. [ 74.702705] ERROR: No se puede manejar el acceso a los datos del núcleo en lectura en 0xc00000005e980000 [ 74.703727] Dirección de instrucción con fallo: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Acceso a datos) en [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 actual = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> ingresar ? para ayuda [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: núcleo: mantener indicadores irq en device_pm_check_callbacks() La función device_pm_check_callbacks() se puede llamar bajo el bloqueo de giro (en el caso informado, ocurre desde genpd_add_device() -> dev_pm_domain_set(), cuando genpd usa bloqueos de giro en lugar de mutexes. Sin embargo, esta función usa spin_lock_irq() / spin_unlock_irq() de manera incondicional, por lo que no conserva los indicadores de la CPU. Use irqsave/irqrestore en su lugar. El backtrace para la referencia: [ 2.752010] ------------[ corte aquí ]------------ [ 2.756769] raw_local_irq_restore() llamado con IRQ habilitados [ 2.762596] ADVERTENCIA: CPU: 4 PID: 1 en kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50 [ 2.772338] Módulos vinculados en: [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Contaminado: GS 5.17.0-rc6-00384-ge330d0d82eff-dirty #684 [ 2.781384] Liberando memoria initrd: 46024K [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50 [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50 [ 2.785846] sp : ffff80000805b7d0 [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002 [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800 [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00 [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7 [ 2.853108] x14: 000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8 [ 2.860441] x11: 00000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0 [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0 [ 2.875107] x5 : 000000000000bff4 x4 : 000000000000000 x3 : 000000000000000 [ 2.882440] x2 : 000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000 [ 2.889774] Rastreo de llamadas: [ 2.892290] warn_bogus_irq_restore+0x34/0x50 [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0 [ 2.901690] genpd_unlock_spin+0x20/0x30 [ 2.905724] genpd_add_device+0x100/0x2d0 [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190 [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0 [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30 [ 2.929102] psci_dt_attach_cpu+0x24/0x90 [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c [ 2.937534] platform_probe+0x68/0xe0 [ 2.941304] really_probe.part.0+0x9c/0x2fc [ 2.945605] __driver_probe_device+0x98/0x144 [ 2.950085] driver_probe_device+0x44/0x15c [ 2.954385] __device_attach_driver+0xb8/0x120 [ 2.958950] bus_for_each_drv+0x78/0xd0 [ 2.962896] __device_attach+0xd8/0x180 [ 2.966843] device_initial_probe+0x14/0x20 [ 2.971144] bus_probe_device+0x9c/0xa4 [ 2.975092] device_add+0x380/0x88c [ 2.978679] platform_device_add+0x114/0x234 [ 2.983067] platform_device_register_full+0x100/0x190 [ 2.988344] psci_idle_init+0x6c/0xb0 [ 2.992113] do_one_initcall+0x74/0x3a0 [ 2.996060] kernel_init_freeable+0x2fc/0x384 [ 3.000543] kernel_init+0x28/0x130 [ 3.004132] ret_from_fork+0x10/0x20 [ 3.007817] marca de evento irq: 319826 [ 3.011404] hardirqs se habilitó por última vez en (319825): [] __up_console_sem+0x78/0x84 [ 3.020332] hardirqs se desactivó por última vez en (319826): [] el1_dbg+0x24/0x8c [ 3.028458] softirqs se habilitó por última vez en (318312): [] _stext+0x410/0x588 [ 3.036678] softirqs se deshabilitó por última vez en (318299): [] __irq_exit_rcu+0x158/0x174 [ 3.045607] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bfq: se corrige el use-after-free en bfq_dispatch_request KASAN informa un informe de use-after-free al realizar una prueba scsi-mq normal [69832.239032] ======================================================================== [69832.241810] ERROR: KASAN: use-after-free en bfq_dispatch_request+0x1045/0x44b0 [69832.243267] Lectura de tamaño 8 en la dirección ffff88802622ba88 por la tarea kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H No contaminado 5.10.0-10295-g576c6382529e #8 [69832.246626] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 [69832.249069] Cola de trabajo: kblockd blk_mq_run_work_fn [69832.250022] Seguimiento de llamadas: [69832.250541] dump_stack+0x9b/0xce [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0 [69832.252243] print_address_description.constprop.6+0x3e/0x60 [69832.253381] ? __cpuidle_text_end+0x5/0x5 [69832.254211] ? vprintk_func+0x6b/0x120 [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0 [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0 [69832.256914] kasan_report.cold.9+0x22/0x3a [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0 [69832.258755] check_memory_region+0x1c1/0x1e0 [69832.260248] bfq_dispatch_request+0x1045/0x44b0 [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440 [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170 [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100 [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570 [69832.267147] ? __switch_to+0x5f4/0xee0 [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270 [69832.269840] blk_mq_run_work_fn+0x51/0x60 [69832.278170] process_one_work+0x6d4/0xfe0 [69832.278984] worker_thread+0x91/0xc80 [69832.279726] ? __kthread_parkme+0xb0/0x110 [69832.280554] ? process_one_work+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthread_park+0x170/0x170 [69832.282849] ret_from_fork+0x1f/0x30 [69832.283573] [69832.283886] Asignado por la tarea 7725: [69832.284599] kasan_save_stack+0x19/0x40 [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmem_cache_alloc_node+0x13f/0x460 [69832.287237] bfq_get_queue+0x3d4/0x1140 [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510 [69832.289015] bfq_init_rq+0x337/0x2d50 [69832.289749] bfq_insert_requests+0x304/0x4e10 [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390 [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760 [69832.292538] blk_flush_plug_list+0x2c5/0x480 [69832.293392] io_schedule_prepare+0xb2/0xd0 [69832.294209] io_schedule_timeout+0x13/0x80 [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270 [69832.296137] submit_bio_wait+0x103/0x1a0 [69832.296932] blkdev_issue_discard+0xe6/0x160 [69832.297794] blk_ioctl_discard+0x219/0x290 [69832.298614] blkdev_common_ioctl+0x50a/0x1750 [69832.304715] blkdev_ioctl+0x470/0x600 [69832.305474] block_ioctl+0xde/0x120 [69832.306232] vfs_ioctl+0x6c/0xc0 [69832.306877] __se_sys_ioctl+0x90/0xa0 [69832.307629] do_syscall_64+0x2d/0x40 [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasan_save_stack+0x19/0x40 [69832.311121] kasan_set_track+0x1c/0x30 [69832.311868] kasan_set_free_info+0x1b/0x30 [69832.312699] __kasan_slab_free+0x111/0x160 [69832.313524] kmem_cache_free+0x94/0x460 [69832.314367] bfq_put_queue+0x582/0x940 [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0 [69832.317275] bfq_bfqq_expire+0xb27/0x2440 [69832.318084] bfq_dispatch_request+0x697/0x44b0 [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270 [69832.323114] blk_mq_run_work_fn+0x51/0x6 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwrng: cavium - corrige el error de coccicheck NULL pero desreferenciado Corrige la siguiente advertencia de coccicheck: ./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR: pdev es NULL pero desreferenciado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memstick/mspro_block: se corrige la gestión de dispositivos de solo lectura. Use set_disk_ro para propagar el estado de solo lectura a la capa de bloque en lugar de verificarlo en ->open y filtrar una referencia en el caso de un dispositivo de solo lectura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Se corrige el mensaje de advertencia debido a que se vaciaba adisc Se corrige el mensaje de advertencia debido a que se vaciaba adisc. El kernel de Linux activó un mensaje de advertencia cuando un tipo de código de error diferente no coincide con el tipo esperado. Agregue una traducción adicional de un tipo de código de error a otro. ADVERTENCIA: CPU: 2 PID: 1131623 en drivers/scsi/qla2xxx/qla_init.c:498 qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] CPU: 2 PID: 1131623 Comm: drmgr No contaminado 5.13.0-rc1-autotest #1 .. GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000 NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] Call Trace: [c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (no confiable) [c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx] [c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx] [c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx] [c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx] [c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120 [c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0 [c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100 [c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40 [c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130 [c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [ c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180 [c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60 [c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20] [c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290 [c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0 [c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330 [c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130 [c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0 [c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Implementar recuento de referencias para SRB El controlador de tiempo de espera y la función done están en ejecución. Cuando qla2x00_async_iocb_timeout() comienza a ejecutarse, puede ser interrumpido por la ruta de respuesta normal (¿a través del firmware?). qla24xx_async_gpsc_sp_done() libera el SRB incondicionalmente. Al programar de nuevo a qla2x00_async_iocb_timeout(), qla24xx_async_abort_cmd() accederá a un puntero sp->qpair liberado: qla2xxx [0000:83:00.0]-2871:0: Tiempo de espera de Async-gpsc - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc SALIDA WWPN 20:45:00:27:f8:75:33:00 velocidades=2c00 velocidad=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx] La solución obvia para esto es introducir un contador de referencia. Se toma una referencia para la ruta de código normal (el caso "bueno") y otra para la ruta de tiempo de espera. Como siempre corremos entre el caso bueno normal y el controlador de tiempo de espera/aborto, necesitamos serializarlo. Además, no podemos asumir ningún orden entre los controladores. Dado que esta es una ruta lenta, podemos usar la sincronización adecuada a través de bloqueos. Cuando podemos cancelar un temporizador (del_timer devuelve 1), sabemos que no puede haber ningún manejo de errores en curso porque el manejador de tiempo de espera aún no ha expirado, por lo que podemos disminuir de manera segura el contador de referencias en uno. Si no podemos cancelar el temporizador, sabemos que se está ejecutando un manejador de aborto. Tenemos que asegurarnos de llamar a sp->done() en los manejadores de aborto antes de llamar a kref_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Se corrige un fallo durante la prueba de carga y descarga de módulos. Durante la gestión de paquetes de Purex, el controlador estaba liberando incorrectamente una estructura preasignada. Solucione este problema omitiendo esa entrada. El sistema se bloqueaba con la siguiente pila durante una prueba de descarga de módulos. Rastreo de llamadas: sbitmap_init_node+0x7f/0x1e0 sbitmap_queue_init_node+0x24/0x150 blk_mq_init_bitmaps+0x3d/0xa0 blk_mq_init_tags+0x68/0x90 blk_mq_alloc_map_and_rqs+0x44/0x120 blk_mq_alloc_set_map_and_rqs+0x63/0x150 blk_mq_alloc_tag_set+0x11b/0x230 scsi_add_host_with_dma.cold+0x3f/0x245 qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx] Rastreo de llamadas con slub_debug y núcleo de depuración: kasan_report_invalid_free+0x50/0x80 __kasan_slab_free+0x137/0x150 slab_free_freelist_hook+0xc6/0x190 kfree+0xe8/0x2e0 qla2x00_free_device+0x3bb/0x5d0 [qla2xxx] qla2x00_remove_one+0x668/0xcf0 [qla2xxx]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: Se corrige la gestión de errores en mt8183_da7219_max98357_dev_probe El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put() en la ruta regular. Y provocará una fuga de refcount en las rutas de error. Corrija esto llamando también a of_node_put() en la gestión de errores.