Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/ipoib: Corrección de advertencia causada por la destrucción de redes no iniciales. Después de la confirmación 5ce2dced8e95 ("RDMA/ipoib: Establecer rtnl_link_ops para interfaces ipoib"), si el dispositivo IPoIB se mueve a redes no iniciales, destruir esas redes permite que el dispositivo desaparezca en lugar de moverlo nuevamente a las redes iniciales. Esto sucede porque default_device_exit() omite las interfaces debido a que tiene rtnl_link_ops configurado. Pasos para reproducir: ip netns agregar foo ip link set mlx5_ib0 netns foo ip netns eliminar foo ADVERTENCIA: CPU: 1 PID: 704 en net/core/dev.c:11435 netdev_exit+0x3f/0x50 Módulos vinculados en: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ip v4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d fuse CPU: 1 PID: 704 Comm: kworker/u64:3 Contaminado: GSW 5.13.0-rc1+ #1 Nombre de hardware: Dell Inc. PowerEdge R6 30/02C2CP, BIOS 2.1.5 11/04/2016 Cola de trabajo: netns cleanup_net RIP: 0010:netdev_exit+0x3f/0x50 Código: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48 8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 RSP: 0018:ffffb297079d7e08 : 00010206 RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX : 000000008010000d RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00 RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ff9fdeac00 R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620 R13: ffffffffa1545628 R14: 00000000000000000 R15: ffffffffa1543b20 FS: 0000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0 0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ops_exit _list.isra.9 +0x36/0x70 cleanup_net+0x234/0x390 Process_one_work+0x1cb/0x360 ? Process_one_work+0x360/0x360 worker_thread+0x30/0x370 ? Process_one_work+0x360/0x360 kthread+0x116/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 Para evitar la advertencia anterior y más adelante el pánico del kernel que podría ocurrir al cerrar debido a una desreferencia del puntero NULL, asegúrese de configurar el indicador netns_refund que fue introducido por la confirmación 3a5ca857079e ("can: dev: Mueva el dispositivo nuevamente a init netns al poseer netns eliminar") para restaurar correctamente las interfaces IPoIB a las netns iniciales.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: corrige varios fallos de dispositivos en cableado de 10 gbps usb_assign_descriptors() se llama con 5 parámetros, los últimos 4 de los cuales son usb_descriptor_header para: velocidad completa (USB1.1 - 12Mbps [ incluyendo USB1.0 de baja velocidad a 1,5 Mbps), alta velocidad (USB2.0 - 480 Mbps), súper velocidad (USB3.0 - 5 Gbps), súper velocidad plus (USB3.1 - 10 Gbps). Las diferencias entre los descriptores de velocidad completa/alta/supervelocidad suelen ser sustanciales (debido a cambios en el tamaño máximo del bloque USB de 64 a 512 a 1024 bytes y otras diferencias en las especificaciones), mientras que la diferencia entre los descriptores de 5 y 10 Gbps puede ser tan casi nada (en muchos casos, la misma afinación es simplemente suficiente). Sin embargo, si un controlador de dispositivo llama a usb_assign_descriptors() con un descriptor NULL para super-speed-plus y luego se usa en una configuración máxima de 10 gbps, el kernel fallará con una desreferencia de puntero null, cuando un puerto de dispositivo con capacidad de 10 gbps + cable + puerto de host Aparece la combinación. (Esto no sucedería si la velocidad máxima del dispositivo estuviera configurada en 5 gbps, pero, por supuesto, está predeterminada al máximo y no hay ninguna razón real para limitarla artificialmente). La solución es simplemente usar el descriptor de 5 gbps como el descriptor de 10 gbps, si no se proporcionó un descriptor de 10 gbps. Obviamente, esto no solucionará el problema si el descriptor de 5 gbps también es NULL, pero estos casos no se pueden resolver de manera tan trivial (y es poco probable que dichos dispositivos se utilicen con puertos USB3 de alguna manera).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: cancela vdm y state machine hrtimer cuando se cancela el registro del puerto tcpm. Un hrtimer pendiente puede caducar después de que se destruya el kthread_worker del puerto tcpm; consulte el siguiente volcado del kernel cuando se descarga el módulo , solucionelo cancelando los 2 temporizadores. [ 111.517018] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff8000118cb880 [ 111.518786] blk_update_request: error de E/S, dev sda, sector 60061185 op 0x0:(LEER) indicadores 0x0 phys_seg 1 prio clase 0 [ 111.526594] Información de cancelación de memoria: [111.526597 ] ESR = 0x96000047 [ 111.526600] EC = 0x25: DABT (EL actual), IL = 32 bits [ 111.526604] SET = 0, FnV = 0 [ 111.526607] EA = 0, S1PTW = 0 [ 111.526610] Información de cancelación de datos: [ 111. 526612 ] ISV = 0, ISS = 0x00000047 [ 111.526615] CM = 0, WnR = 1 [ 111.526619] tabla de intercambio: páginas de 4k, VA de 48 bits, pgdp=0000000041d75000 [ 111.526623 [ffff8000118cb] 880] pgd=10000001bffff003, p4d=10000001bffff003, pudín =10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000 [111.526642] Error interno: Ups: 96000047 [#1] SMP PREEMPLEO [111.526647] Módulos vinculados en: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [última descarga: tcpci] [111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36 [111.526670] Nombre del hardware: placa NXP i.MX8MPlus EVK (DT) [111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--) [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390 [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4 [ 111.526703] sp : ffff800010003e20 [ 111.526 706] x29: ffff800010003e20 x28: ffff00017f380180 [111.537156] buffer_io_error: 6 devoluciones de llamada suprimidas [111.537162 ] Error de E/S del búfer en dev sda1, bloque lógico 60040704, lectura de página asíncrona [111.539932] x27: ffff00017f3801c0 [111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 00000000000001 [111.543025] blk_update_request: error de E/S, dev sda, sector 60061186 op 0x0:(LEER) banderas 0x0 phys_seg 7 prio clase 0 [ 111.548304] [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180 [ 111.551 374] Error de E/S del búfer en dev sda1, bloque lógico 60040705, lectura de página asíncrona [111.554499] [111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000 [111.557391] Error de E/S del búfer en dev sda1, bloque lógico 60040706, lectura de página asíncrona [111. 561218] [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 00000000000000000 [ 111.564205] Búfer Error de E/S en dev sda1, bloque lógico 60040707, lectura de página asíncrona [111.570887] x14: 00000000000000f5 x13: 00000000000000001 x12: 0000000000000040 [111.570902] x11: ff0000c05ac6d8 [111.583420] Error de E/S del búfer en dev sda1, bloque lógico 60040708, asíncrono lectura de página [111.588978] x10: 0000000000000000 x9: 0000000000040000 [111.588988] x8: 0000000000000000 [111.597173] Error de E/S del búfer en dev sda1, bloque lógico 6004 0709, lectura de página asíncrona [111.605766] x7: ffff00017f384880 x6: ffff8000118cb880 [111.605777] x5: ffff00017f384880 [111.611094] Error de E/S del búfer en dev sda1, bloque lógico 60040710, lectura de página asíncrona [111.617086] x4: 0000000000000000 x3: ffff0000c2a9f184 [111.617096] 2: ffff8000118cb880 [111.622242] Error de E/S del búfer en dev sda1, bloque lógico 60040711 , lectura de página asíncrona [111.626927] x1: ffff8000118cb880 x0: ffff00017f384888 [111.626938] Seguimiento de llamadas: [111.626942] queued_spin_lock_slowpath+0x1a0/0x390 [111.795809] _queue_work+0x30/0xc0 [ 111.799828] state_machine_timer_handler+0x20/0x30 [ 111.804624] __hrtimer_run_queues+0x140/ 0x1e0 [ 111.808990] hrtimer_interrupt+0xec/0x2c0 [ 111.813004] arch_timer_handler_phys+0x38/0x50 [ 111.817456] handle_percpu_devid_irq+0x88/0x150 [ 111.821991] main_irq+0x80/0xe0 [ 111.826093] gic_handle_irq+0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: ep0: corrige excepción de puntero NULL. No hay validación del índice desde dwc3_wIndex_to_dep() y podríamos estar haciendo referencia a un ep inexistente y desencadenar una excepción de puntero NULL. En ciertas configuraciones, podríamos usar menos eps y el índice podría indicar erróneamente un índice ep mayor que el existente. Al agregar esta validación del parche, podemos informar un índice incorrecto a la persona que llama. En nuestro caso de uso, estamos usando un dispositivo compuesto en un kernel más antiguo, pero el nivel superior también podría usar esta solución. Desafortunadamente, no puedo describir el hardware para que otros reproduzcan el problema ya que es una implementación propietaria. [82.958261] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000a4 [82.966891] Información de cancelación de memoria: [82.969663] ESR = 0x96000006 [82.972703] Clase de excepción = DABT (EL actual), IL = 32 bits [ 82.9 78603] CONFIGURAR = 0, FnV = 0 [82.981642] EA = 0, S1PTW = 0 [82.984765] Información de cancelación de datos: [82.987631] ISV = 0, ISS = 0x00000006 [82.991449] CM = 0, WnR = 0 [82.994409] tabla de usuario 4k: páginas, 39 VA de bits, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.00 9685] Error interno: Oops: 96000006 [#1] SMP PREEMPTO [83.026433] Proceso irq/62-dwc3 (pid : 303, límite de pila = 0x000000003985154c) [83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 No contaminado 4.19.124 #1 [83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 49628] ordenador personal: dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Rastreo de llamadas: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148 823] dwc3_ep0_interrupt+0x3b4/0xc94 [83.181546] ---[ final de seguimiento aac6b5267d84c32f ]---

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: repara varios gadgets null ptr deref en cableado de 10gbps. Esto evita una desreferencia de puntero null en f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} simplemente reutilizando la configuración de 5 gbps para 10 gbps.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: cdnsp: soluciona el problema de interbloqueo en cdnsp_thread_irq_handler. El parche corrige el siguiente problema crítico causado por el interbloqueo que se detectó durante las pruebas Clase NCM: smp: csd: se detectó un bloqueo CSD que no responde ( #1) en CPU#0 smp: csd: el bloqueo CSD (#1) no responde. .... RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0 RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002 RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 00000000000000000 R 10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: 00000000000000246 R15: ffff9ee8116b4658 CS: 0010 DS: 0 ES: 0000 CR0: 0000000080050033 CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0 Seguimiento de llamadas: do_raw_spin_lock+0xc0/0xd0 _raw_spin_lock_irqsave + 0x95/0xa0 cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci] usb_ep_queue+0x35/0x110 eth_start_xmit+0x220/0x3d0 [u_ether] ncm_tx_timeout+0x34/0x40 [usb_f_ncm] ? ncm_free_inst+0x50/0x50 [usb_f_ncm] __hrtimer_run_queues+0xac/0x440 hrtimer_run_softirq+0x8c/0xb0 __do_softirq+0xcf/0x428 asm_call_irq_on_stack+0x12/0x20 +0x61/0x70 irq_exit_rcu+0xc1/0xd0 sysvec_apic_timer_interrupt+0x52/0xb0 asm_sysvec_apic_timer_interrupt+0x12 /0x20 RIP: 0010:do_raw_spin_trylock+0x18/0x40 RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246 RAX: 00000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000 000 RDX: 0000000000000001 RSI: 00000000000000000 RDI: ffff9ee8116b4658 RBP: ffffbc494138bda8 R08: 00000000000000001 R09: 0000000000000000 R10: ffff9ee8116b4670 R11 : 0000000000000000 R12: ffff9ee8116b4658 R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000 _raw_spin_lock+0x3d/0x70 ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci] ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci] ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci] ? irq_thread+0xa0/0x1c0 irq_thread_fn+0x28/0x60 irq_thread+0x105/0x1c0 ? __kthread_parkme+0x42/0x90 ? irq_forced_thread_fn+0x90/0x90? wake_threads_waitq+0x30/0x30? irq_thread_check_affinity+0xe0/0xe0 kthread+0x12a/0x160 ? kthread_park+0x90/0x90 ret_from_fork+0x22/0x30 La causa principal del problema es la instrucción spin_lock/spin_unlock en lugar de spin_lock_irqsave/spin_lock_irqrestore en la función cdnsp_thread_irq_handler.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Bail from dwc3_gadget_exit() si dwc->gadget es NULL. Existe un posible escenario en el que dwc3_gadget_init() puede fallar: durante durante el host -> modo periférico Cambie a dwc3_set_mode() y un controlador de dispositivo pendiente no se vincula. Luego, si el DRD sufre otro cambio de modo desde periférico->host, el dwc3_gadget_exit() resultante intentará hacer referencia a un puntero dwc->gadget no válido y colgante, así como llamar a dma_free_coherent() en punteros DMA no asignados. El escenario exacto se puede reproducir de la siguiente manera: - Iniciar DWC3 en modo periférico - Configurar el gadget ConfigFS con la instancia FunctionFS (o usar g_ffs) - Ejecutar la aplicación de espacio de usuario FunctionFS (abrir EP, escribir descriptores, etc.) - Vincular el controlador del gadget al UDC de DWC3 - Cambiar DWC3 al modo host => se llama a dwc3_gadget_exit(). usb_del_gadget() colocará la instancia del controlador ConfigFS en gadget_driver_pending_list - Detener la aplicación FunctionFS (cierra los archivos ep) - Cambiar DWC3 al modo periférico => dwc3_gadget_init() falla ya que usb_add_gadget() llama a check_pending_gadget_drivers() e intenta volver a vincular el UDC al El gadget ConfigFS pero falla con -19 (-ENODEV) porque la instancia FFS no está en estado FFS_ACTIVE (el espacio de usuario aún no se ha reabierto ni escrito los descriptores, es decir, desc_ready!=0). - Vuelva a cambiar DWC3 al modo host => se vuelve a llamar a dwc3_gadget_exit(), pero esta vez dwc->gadget no es válido. Aunque se puede argumentar que el espacio de usuario debe asumir la responsabilidad de garantizar que la aplicación FunctionFS esté lista antes de permitir que el controlador compuesto se vincule al UDC, no hacerlo no debería generar pánico por parte del controlador del kernel. Solucione este problema configurando dwc->gadget en NULL en la ruta de falla de dwc3_gadget_init() y agregue una marca a dwc3_gadget_exit() para salir del problema a menos que el puntero del gadget sea válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-meson-g12a: repara el init de glue PHY de usb2 cuando phy0 está deshabilitado. Cuando solo se usa PHY1 (por ejemplo, en Odroid-HC4), el código de inicio de regmap usa usb2 puertos cuando no inicializa la entrada del mapa de registro PHY1. Esto soluciona: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000020... pc: regmap_update_bits_base+0x40/0xa0 lr: dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8... Seguimiento de llamadas: regmap_update_bits_base+0x40/0xa0 g12a_usb2_init_phy+0x4c/0xf8 dwc3_meson_g12a_usb2_init+0x7c /0xc8 dwc3_meson_g12a_usb_init+0x28/0x48 dwc3_meson_g12a_probe+0x298/0x540 platform_probe+0x70/0xe0 Actually_probe+0xf0/0x4d8 driver_probe_device+0xfc/0x168 ...

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rastreo: corrija la verificación de longitud que causa corrupción de la memoria. Hemos sufrido fallos graves del kernel debido a la corrupción de la memoria en nuestro entorno de producción, como Call Trace: [1640542.554277] fallo de protección general. : 0000 [#1] SMP PTI [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: cargado Contaminado:G [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190 [1640542.559074] : 0018:ffffb16faa597df8 EFLAGS: 00010286 [ 1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX: 0000000006e931bf [1640542.560323] RDX: 0000000006e931be RSI: 0000400200 RDI: ffff9a45ff004300 [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09: 0000000000000000 [1640542.561670] : 0000000000000000 R11: 0000000000000000 R12: ffffffff9a20608d [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15: 696c662f65636976 [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000) GS:0000000000000000 [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4: 00000000003606e0 [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1640542.5 66069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1640542.566742] Seguimiento de llamadas: [1640542.567009] anon_vma_clone+0x5d/0x170 2.567417] __split_vma+0x91/0x1a0 [1640542.567777] do_munmap+0x2c6/0x320 [1640542.568128] vm_munmap+0x54/0x70 [1640542.569990] __x64_sys_munmap+0x22/0x30 [1640542.572005] _64+0x5b/0x1b0 [1640542.573724] entrada_SYSCALL_64_after_hwframe+0x44/0xa9 [1640542.575642] RIP: 0033:0x7f45d6e61e27 James Wang lo ha reproducido de forma estable en la última versión 4.19 LTS. Después de algunas depuraciones, finalmente demostramos que se debe al acceso fuera de los límites al búfer ftrace usando una herramienta de depuración de la siguiente manera: [86.775200] ERROR: Escritura fuera de los límites en la dirección 0xffff88aefe8b7000 [86.780806] no_context+0xdf/0x3c0 [86.784327 ] __do_page_fault+0x252/0x470 [ 86.788367] do_page_fault+0x32/0x140 [ 86.792145] page_fault+0x1e/0x30 [ 86.795576] strncpy_from_unsafe+0x66/0xb0 [ 86.799789] ry_string+0x25/0x40 [ 86.804002] fetch_deref_string+0x51/0x60 [ 86.808134] kprobe_trace_func +0x32d/0x3a0 [ 86.812347] kprobe_dispatcher+0x45/0x50 [ 86.816385] kprobe_ftrace_handler+0x90/0xf0 [ 86.820779] ftrace_ops_assist_func+0xa1/0x140 [ 86.825340] ffffc00750bf [ 86.828603] do_sys_open+0x5/0x1f0 [ 86.832124] do_syscall_64+0x5b/0x1b0 [ 86.835900 ] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 commit b220c049d519 ("rastreo: verificar la longitud antes de entregar el búfer de filtro") agrega verificación de longitud para proteger el desbordamiento de datos de seguimiento introducido en 0fc1b09ff1ff, parece que esta solución no puede evitar el desbordamiento por completo, la verificación de longitud también debería tenga en cuenta el tamaño de la entrada->matriz[0], ya que esta matriz[0] ocupa toda la longitud de los datos de seguimiento y ocupa espacio adicional y corre el riesgo de desbordarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: evita solicitudes de lectura de gran tamaño en la ruta del código faltante de la caché. En la ruta del código faltante de la caché del dispositivo almacenado en caché, si una ubicación adecuada del árbol B+ interno coincide con un rango de falta de caché, La función cached_dev_cache_miss() se llamará en cache_lookup_fn() en el siguiente bloque de código, [bloque de código 1] 526 unsigned int sectores = KEY_INODE(k) == s->iop.inode 527? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529: INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Aquí s->d->cache_miss() es el puntero de función de devolución de llamada inicializado como cached_dev_cache_miss(), el último parámetro 'sectors' es una pista importante para calcular el tamaño de la solicitud de lectura al dispositivo de respaldo de los datos de caché faltantes. El cálculo actual en el bloque de código anterior puede generar un valor sobredimensionado de 'sectors', lo que en consecuencia puede desencadenar 2 posibles pánicos del kernel diferentes mediante BUG() o BUG_ON() como se enumera a continuación, 1) BUG_ON() dentro de bch_btree_insert_key(), [bloque de código 2 ] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() dentro de biovec_slab(), [bloque de código 3] 51 predeterminado: 52 BUG(); 53 devuelve NULO; Todos los pánicos anteriores son originales de cached_dev_cache_miss() por el parámetro 'sectors' de gran tamaño. Dentro de cached_dev_cache_miss(), el parámetro 'sectors' se utiliza para calcular el tamaño de los datos leídos desde el dispositivo de respaldo para el caché que falta. Este tamaño se almacena en s->insert_bio_sectors mediante las siguientes líneas de código, [bloque de código 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Luego, la clave real que se inserta en el árbol B+ interno se genera y almacena en s->iop.replace_key mediante las siguientes líneas de código, [bloque de código 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insertar_bio_sectores, 913 s->insertar_bio_sectores); El parámetro 'sectors' de gran tamaño puede provocar pánico 1) mediante BUG_ON() del bloque de código anterior. Y el envío de biografía al dispositivo de respaldo para los datos faltantes se asigna con una sugerencia de s->insert_bio_sectors mediante las siguientes líneas de código, [bloque de código 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); Los 'sectors' de parámetros de gran tamaño pueden provocar pánico 2) mediante BUG() desde el bloque de código anterior. Ahora permítanme explicar cómo se produce el pánico en los "sectors" sobredimensionados. En el bloque de código 5, replace_key se genera mediante la macro KEY(). De la definición de macro KEY(), [bloque de código 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) ( tamaño) << 20) | (inodo), \ 74 .low = (desplazamiento) \ 75 }) Aquí 'tamaño' es un ancho de 16 bits incrustado en el miembro 'alto' de 64 bits de la estructura bkey. Pero en el bloque de código 1, si "KEY_START(k) - bio->bi_iter.bi_sector" es muy probable que sea mayor que (1<<16) - 1, lo que hace que el cálculo del tamaño de la clave b en el bloque de código 5 se desborde. En un informe de error, el valor del parámetro 'sectors' es 131072 (= 1 << 17), los 'sectors' desbordados dan como resultado s->insert_bio_sectors desbordados en el bloque de código 4, luego convierte el campo de tamaño de s->iop.replace_key en sea 0 en el bloque de código 5. Luego, el tamaño 0 s->iop.replace_key se inserta en el árbol B+ interno como clave de verificación de falta de caché (una clave especial para detectar y evitar una ejecución entre la solicitud de escritura normal y la solicitud de lectura faltante de caché) como, [bloque de código 8] 915 ret = ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ftrace: no lea ciegamente la dirección IP en ftrace_bug(). Se informó que un error en arm64 provocó que se usara una dirección IP incorrecta para actualizar a un nop en ftrace_init() , pero la ruta de error (con razón) devolvió -EINVAL y no -EFAULT, ya que el error provocó que ocurriera más de un error. Pero debido a que se devolvió -EINVAL, ftrace_bug() intentó informar qué había en la ubicación de la dirección IP y leerlo directamente. Esto provocó que la máquina entrara en pánico, ya que la IP no apuntaba a una dirección de memoria válida. En su lugar, lea la dirección IP con copy_from_kernel_nofault() para acceder de forma segura a la memoria y, si falla, informe que la dirección falló; de lo contrario, informe qué había en esa ubicación.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mac80211: corrige la verificación de longitud de skb en ieee80211_scan_rx() Reemplace las constantes de tiempo de compilación codificadas para la verificación de la longitud del encabezado con determinación dinámica basada en el tipo de trama. De lo contrario, obtendremos un WARN_ON de validación en cfg80211 más adelante. [correcciones de estilo, reformular mensaje de confirmación]