Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: smscufx: Corregir null-ptr-deref en ufx_usb_probe() Recibí un informe de null-ptr-deref: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Seguimiento de llamadas: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 Si fb_alloc_cmap() falla en ufx_usb_probe(), fb_destroy_modelist() Se llamará a modelist para destruirlo en la ruta de manejo de errores. Pero modelist aún no se ha inicializado, por lo que dará como resultado null-ptr-deref. Inicialice modelist antes de llamar a fb_alloc_cmap() para corregir este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath5k: corrección de OOB en ath5k_eeprom_read_pcal_info_5111 El error se encontró durante el fuzzing. Stacktrace lo ubica en ath5k_eeprom_convert_pcal_info_5111. Cuando no se selecciona ninguna de las curvas en el bucle, idx puede llegar hasta AR5K_EEPROM_N_PD_CURVES. La línea hace que pd esté fuera de los límites. pd = &chinfo[pier].pd_curves[idx]; Hay muchas escrituras OOB que usan pd más adelante en el código. Así que agregué una verificación de cordura para idx. No se necesitan verificaciones para otros bucles que involucran AR5K_EEPROM_N_PD_CURVES ya que el índice del bucle no se usa fuera de los bucles. El parche NO se prueba con un dispositivo real. El siguiente es el informe de fuzzing ERROR: KASAN: slab-out-of-limits en ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Escritura de tamaño 1 en la dirección ffff8880174a4d60 por la tarea modprobe/214 CPU: 0 PID: 214 Comm: modprobe No contaminado 5.6.0 #1 Seguimiento de llamadas: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 realmente_probe+0x209/0x5d0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubi: Se corrige la condición de ejecución entre ctrl_cdev_ioctl y ubi_cdev_ioctl Hulk Robot informó un informe de KASAN sobre use-after-free: ====================================================================== ERROR: KASAN: use-after-free en __list_del_entry_valid+0x13d/0x160 Lectura de tamaño 8 en la dirección ffff888035e37d98 por la tarea ubiattach/1385 [...] Seguimiento de llamadas: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Asignado por la tarea 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Liberado por la tarea 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ===================================================================== El bloqueo retenido por ctrl_cdev_ioctl es ubi_devices_mutex, pero el bloqueo retenido por ubi_cdev_ioctl es ubi->device_mutex. Por lo tanto, los dos bloqueos pueden ser concurrentes. ctrl_cdev_ioctl contiene dos operaciones: ubi_attach y ubi_detach. ubi_detach está libre de errores porque utiliza el conteo de referencias para evitar la concurrencia. Sin embargo, uif_init y uif_close en ubi_attach pueden competir con ubi_cdev_ioctl. uif_init competirá con ubi_cdev_ioctl como en la siguiente pila. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs existen kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // primer ubi_free_volume libre cdev_del // doble liberación cdev_device_del Y uif_close competirá con ubi_cdev_ioctl como en la siguiente pila. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // primera liberación ubi_free_volume // doble liberación La causa de este problema es que la confirmación 714fb87e8bc0 hace que el dispositivo esté "disponible" antes de que se pueda acceder a él a través de sysfs. Por lo tanto, revertimos la modificación. Solucionaremos la condición de ejecución entre la creación del dispositivo ubi y udev eliminando ubi_get_device en vol_attribute_show y dev_attribute_show. Esto evita el acceso a ubi_devices[ubi_num] no inicializados. ubi_get_device se utiliza para evitar que se eliminen los dispositivos durante la ejecución de sysfs. Sin embargo, ahora kernfs garantiza que los dispositivos no se eliminarán antes de que se liberen todos los recuentos de referencias. El proceso clave se muestra en la siguiente pila. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Corrección para agregar refcount una vez que la página se establece como privada MM definió la regla [1] muy claramente que una vez que la página se establece con el indicador PG_private, debemos incrementar el refcount en esa página, también los flujos principales como pageout(), migrants_page() asumirán que hay un recuento de referencia de página adicional si page_has_private() devuelve verdadero. De lo contrario, podemos obtener un ERROR en la migración de la página: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) página volcada porque: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cortar aquí ]------------ ¡ERROR del kernel en include/linux/page_ref.h:184! código de operación no válido: 0000 [#1] CPU SMP: 3 PID: 38 Comm: kcompactd0 No contaminado 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Rastreo de llamadas: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrants_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Antes de tiempo, deberíamos aclarar un concepto, qué significa refcount en la página obtenida de grab_cache_page_write_begin(). Hay 2 situaciones: Situación 1: refcount es 3, la página es creada por __page_cache_alloc. TYPE_A - el proceso de escritura está usando esta página TYPE_B - la página es asignada a un cierto mapeo llamando a __add_to_page_cache_locked() TYPE_C - la página es agregada a la lista pagevec correspondiente a la CPU actual llamando a lru_cache_add() Situación 2: refcount es 2, la página es obtenida del árbol del mapeo TYPE_B - la página ha sido asignada a un cierto mapeo TYPE_A - el proceso de escritura está usando esta página (llamando a page_cache_get_speculative()) El sistema de archivos libera un refcount llamando a put_page() en xxx_write_end(), el refcount liberado corresponde a TYPE_A (la tarea de escritura lo está usando). Si hay algún proceso usando una página, el proceso de migración de página omitirá la página al juzgar si expected_page_refs() es igual a page refcount. El ERROR es causado por el siguiente proceso: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // coloca la página en el pagevec de la CPU 0 (refcnf = 3, para el proceso de creación de la página) ubifs_write_end SetPagePrivate(page_a) // ¡no aumenta el número de páginas! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS no aumenta el recuento de referencias de la página después de configurar el indicador privado, lo que hace que la tarea de migración de la página crea que ningún otro proceso utiliza la página, por lo que se migra la página. Esto provoca un acceso simultáneo al recuento de referencias de la página entre put_page() llamado por otro proceso (por ejemplo, el proceso de lectura llama a lru_cache_add) y page_ref_unfreeze() llamado por mi ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Se corrige la lectura fuera de los límites en la función ubifs_wbuf_write_nolock() ubifs_wbuf_write_nolock() puede acceder a buf fuera de los límites en el siguiente proceso: ubifs_wbuf_write_nolock(): classified_len = ALIGN(len, 8); // Supongamos que len = 4089, classified_len = 4096 if (aligned_len <= wbuf->avail) ... // No satisface if (wbuf->used) { ubifs_leb_write() // Complete algunos datos en avail wbuf len -= wbuf->avail; // len aún no está alineado a 8 bytes classified_len -= wbuf->avail; } n = classified_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + escrito, wbuf->offs, n); // n > len, lectura fuera de los límites menor a 8(n-len) bytes }, lo cual puede ser detectado por KASAN: =========================================================== ERROR: KASAN: slab fuera de los límites en ecc_sw_hamming_calculate+0x1dc/0x7d0 Lectura de tamaño 4 en la dirección ffff888105594ff8 por la tarea kworker/u8:4/128 Cola de trabajo: escritura diferida wb_workfn (flush-ubifs_0_0) Rastreo de llamadas: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 La función ubifs_wbuf_write_nolock() acepta que el parámetro 'len' no esté alineado con 8 bytes, 'len' representa la longitud verdadera de buf (que está asignada en 'ubifs_jnl_xxx', p. ej. ubifs_jnl_write_inode), por lo que ubifs_wbuf_write_nolock() debe manejar la longitud leída de 'buf' con cuidado para escribir leb de forma segura. Obtenga un reproductor en [Enlace].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> ubifs: Se corrige interbloqueo en concurrencia de un renombrado con whiteout simultáneo a la escritura del inodo.<br /> <br /> Tareas colgadas:<br /> [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132<br /> [ 77.028820] Call Trace:<br /> [ 77.029027] schedule+0x8c/0x1b0<br /> [ 77.029067] mutex_lock+0x50/0x60<br /> [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs]<br /> [ 77.029117] __writeback_single_inode+0x43c/0x570<br /> [ 77.029128] writeback_sb_inodes+0x259/0x740<br /> [ 77.029148] wb_writeback+0x107/0x4d0<br /> [ 77.029163] wb_workfn+0x162/0x7b0<br /> <br /> [ 92.390442] task:aa state:D stack: 0 pid: 1506<br /> [ 92.390448] Call Trace:<br /> [ 92.390458] schedule+0x8c/0x1b0<br /> [ 92.390461] wb_wait_for_completion+0x82/0xd0<br /> [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110<br /> [ 92.390472] writeback_inodes_sb_nr+0x14/0x20<br /> [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs]<br /> [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs]<br /> [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs]<br /> [ 92.390571] vfs_rename+0xdb2/0x1170<br /> [ 92.390580] do_renameat2+0x554/0x770<br /> <br /> , ocasionado por procesos simultáneos de renombrado con whiteout y escritura del inodo:<br /> rename_whiteout(Thread 1) wb_workfn(Thread2)<br /> ubifs_rename<br /> do_rename<br /> lock_4_inodes (Hold ui_mutex)<br /> ubifs_budget_space<br /> make_free_space<br /> shrink_liability<br /> __writeback_inodes_sb_nr<br /> bdi_split_work_to_wbs (Queue new wb work)<br /> wb_do_writeback(wb work)<br /> __writeback_single_inode<br /> ubifs_write_inode<br /> LOCK(ui_mutex)<br /> ?<br /> wb_wait_for_completion (Wait wb work) &amp;lt;-- ¡interbloqueo!<br /> <br /> Caso de prueba:<br /> 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT)<br /> 2. Consumir todo el espacio antes de que kernel(mdelay) planifique el whiteout<br /> <br /> Arreglado calculando el espacio de whiteout antes de bloquear los inodos de ubifs.<br /> <br /> También soluciona etiqueta la etiqueta goto errónea &amp;#39;out_release&amp;#39; en el flujo de errores<br /> de la planificación del whiteout (al menos debería recuperar el directorio i_size y desbloquear 4 inodos de ubifs).<br />

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: rename_whiteout: Se corrige la doble liberación para whiteout_ui-&amp;gt;data &amp;#39;whiteout_ui-&amp;gt;data&amp;#39; se liberará dos veces si el presupuesto de espacio falla para la operación de cambio de nombre de whiteout como el siguiente proceso: rename_whiteout dev = kmalloc whiteout_ui-&amp;gt;data = dev kfree(whiteout_ui-&amp;gt;data) // Libera la primera vez iput(whiteout) ubifs_free_inode kfree(ui-&amp;gt;data) // ¡Doble liberación! KASAN informa: ==================================================================== ERROR: KASAN: liberación doble o liberación no válida en ubifs_free_inode+0x4f/0x70 Seguimiento de llamadas: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Asignado por la tarea 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Liberado por la tarea 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 La dirección con errores pertenece al objeto en ffff88810238bed8 que pertenece al caché kmalloc-8 de tamaño 8 ===================================================================== Deje que ubifs_free_inode() libere &amp;#39;whiteout_ui-&amp;gt;data&amp;#39;. Por cierto, elimine la asignación no utilizada &amp;#39;whiteout_ui-&amp;gt;data_len = 0&amp;#39;, el proceso &amp;#39;ubifs_evict_inode() -&amp;gt; ubifs_jnl_delete_inode() -&amp;gt; ubifs_jnl_write_inode()&amp;#39; no lo necesita (porque &amp;#39;inc_nlink(whiteout)&amp;#39; no será ejecutado por &amp;#39;goto out_release&amp;#39;, y el nlink del inodo whiteout es 0).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Se eliminan _todos_ las raíces al anular la asignación del rango gfn en TDP MMU Se eliminan las raíces válidas e inválidas al hacer zapping/anular la asignación de un rango gfn, ya que KVM debe asegurarse de que no contiene referencias a la página liberada después de regresar de la operación de anulación de la asignación. En particular, TDP MMU no elimina las raíces inválidas en las devoluciones de llamadas mmu_notifier. Esto conduce a problemas de use-after-free y otros problemas si mmu_notifier se ejecuta hasta el final mientras que un zapper de raíz inválida cede, ya que KVM no cumple con el requisito de que no debe haber _ninguna_ referencia a la página después de que mmu_notifier regrese. El error se reproduce más fácilmente pirateando KVM para provocar una colisión entre set_nx_huge_pages() y kvm_mmu_notifier_release(), pero el error también existe entre kvm_mmu_notifier_invalidate_range_start() y las actualizaciones de memslot. Invalidar una raíz garantiza que el invitado no pueda acceder a las páginas, y KVM no leerá ni escribirá datos de página por sí mismo, pero KVM activará, por ejemplo, kvm_set_pfn_dirty() al hacer zapping de SPTE, y por lo tanto, completar un zapping de una raíz no válida _después_ de que mmu_notifier regrese es fatal. ADVERTENCIA: CPU: 24 PID: 1496 en arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Rastreo de llamadas: kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_raíces_invalidadas+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/kasan: Se solucionó que la región temprana no se actualizara correctamente La tabla de páginas de shadow no se actualiza cuando PTE_RPN_SHIFT es 24 y PAGE_SHIFT es 12. No solo causa falsos positivos sino también falsos negativos como se muestra en el siguiente texto. Arréglelo trayendo la lógica de kasan_early_shadow_page_entry aquí. 1. Falso positivo: ==================================================================== ERROR: KASAN: vmalloc fuera de los límites en pcpu_alloc+0x508/0xa50 Escritura de tamaño 16 en la dirección f57f3be0 por la tarea swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.15.0-12267-gdebe436e77c7 #1 Seguimiento de llamadas: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (no confiable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Estado de la memoria alrededor de la dirección con errores: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 &amp;gt;f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ===================================================================== 2. Falso negativo (con pruebas KASAN): ==================================================================== Antes de la corrección: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATIVA FALLÓ en lib/test_kasan.c:1039 Se esperaba una falla de KASAN en "((volatile char *)area)[3100]", pero no ocurrió ninguna no ok 46 - vmalloc_oob no ok 1 - kasan ======================================================================== Después de la corrección: ok 1 - kasan

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: cirrusfb: comprobar pixclock para evitar la división por cero Realice una comprobación de la depuración del valor de pixclock para evitar la división por cero. Si el valor de pixclock es cero, el controlador cirrusfb redondeará el valor de pixclock para obtener la frecuencia derivada lo más cercana posible a maxclock. Syzkaller informó un error de división en cirrusfb_check_pixclock. Error de división: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test No contaminado 5.15.0-rc6 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Seguimiento de llamadas: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: nvidiafb: Use strscpy() para evitar el desbordamiento del búfer Coverity se queja de un posible desbordamiento del búfer. Sin embargo, dado el alcance &amp;#39;estático&amp;#39; de nvidia_setup_i2c_bus(), parece que eso no puede suceder después de examinar los sitios de llamada. CID 19036 (#1 de 1): Copiar en un búfer de tamaño fijo (STRING_OVERFLOW) 1. fixed_size_dest: Puede desbordar la cadena de tamaño fijo de 48 caracteres chan-&amp;gt;adapter.name copiando name sin verificar la longitud. 2. parameter_as_source: Nota: Este defecto tiene un riesgo elevado porque el argumento source es un parámetro de la función actual. 89 strcpy(chan-&amp;gt;adapter.name, name); Corrija esta advertencia usando strscpy() que silenciará la advertencia y evitará futuros desbordamientos del búfer si los nombres utilizados para identificar el canal se vuelven mucho más largos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: davinci: da850-evm: Evitar la desreferencia de puntero NULL Con versiones más nuevas de GCC, hay un pánico en da850_evm_config_emac() al iniciar multi_v5_defconfig en QEMU bajo la máquina palmetto-bmc: No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Error interno: Oops: 5 [#1] PREEMPT Módulos ARM vinculados: CPU: 0 PID: 1 Comm: swapper No contaminado 5.15.0 #1 Nombre del hardware: Sistema genérico basado en DT La PC está en da850_evm_config_emac+0x1c/0x120 LR está en El puntero emac_pdata en soc_info es NULL porque davinci_soc_info solo se completa en máquinas davinci, pero se llama a da850_evm_config_emac() en todas las máquinas a través de device_initcall(). Mueva la asignación rmii_en debajo de la verificación de la máquina para que solo se desreferencia cuando se ejecuta en un SoC compatible.