Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: libera la cantidad correcta de delalloc en la ruta de escritura de E/S directa. La ejecución de generic/406 provoca la siguiente ADVERTENCIA en btrfs_destroy_inode() que indica que quedan extensiones pendientes. En btrfs_get_blocks_direct_write(), reservamos extensiones pendientes temporalmente con btrfs_delalloc_reserve_metadata() (o indirectamente desde btrfs_delalloc_reserve_space()). Luego, liberamos las extensiones pendientes con btrfs_delalloc_release_extents(). Sin embargo, la "longitud" se puede modificar en el caso de COW, que libera menos extensiones pendientes de lo esperado. Arréglelo llamando a btrfs_delalloc_release_extents() para la longitud original. Para reproducir la advertencia, el sistema de archivos debe ser de 1 GiB. Está activando una escritura corta, debido a que no se puede asignar una extensión grande y, en su lugar, se asigna una más pequeña. ADVERTENCIA: CPU: 0 PID: 757 en fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs] Módulos vinculados en: btrfs blake2b_generic xor lzo_compress lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram zsmalloc CPU: 0 PID: 757 Comm: umount No contaminado 5.17.0-rc8+ #101 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS d55cb5a 01/04/2014 RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs] RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206 RAX: 000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000 RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78 RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8 R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800 R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68 FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: destroy_inode+0x33/0x70 dispose_list+0x43/0x60 evict_inodes+0x161/0x1b0 generic_shutdown_super+0x2d/0x110 kill_anon_super+0xf/0x20 btrfs_kill_super+0xd/0x20 [btrfs] deactivate_locked_super+0x27/0x90 cleanup_mnt+0x12c/0x180 task_work_run+0x54/0x80 exit_to_user_mode_prepare+0x152/0x160 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f854a000fb7

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se solucionó agregando protección FPU para dcn30_internal_validate_bw [Por qué] Se observó una falla de protección general cuando WebGL Aquarium se ejecuta durante un período prolongado. Si los registros de depuración de drm están habilitados y configurados en 0x1f, el problema se observa dentro de los 10 minutos posteriores a la ejecución. [ 100.717056] Fallo de protección general, probablemente para la dirección no canónica 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI [ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: GW 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b [ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f [ 100.767109] Código: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b [ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246 [ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500RCX: 00000000000000000 [ 100.819656] RDX: 00000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000 [ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c [ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44 [ 100.841033] R13: 00000000000000001 R14: 00000000000000000 R15: ffffa9230079f0a0 [ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000 [ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0 [ 100.869106] Seguimiento de llamadas: [ 100.871555] [ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20 [ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd [ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da [ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163 [ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163 [ 100.899874] ? __sprint_symbol+0x80/0x135 [ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2 [ 100.908500] ? symbol_string+0xb7/0xde [ 100.912250] ? number+0x145/0x29b [ 100.915566] ? vsnprintf+0x341/0x5ff [ 100.919141] ? desc_read_finalized_seq+0x39/0x87 [ 100.923755] ? update_load_avg+0x1b9/0x607 [ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b [ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c [ 100.937686] ? dc_fpu_end+0x3d/0xa8 [ 100.941175] dml_get_voltage_level+0x16b/0x180 [ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b [ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc [ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c [ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc [ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc [ 100.970001] dc_validate_global_state+0x238/0x295 [ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce [ 100.979235] ? _printk+0x59/0x73 [ 100.982467] drm_atomic_check_only+0x403/0x78b [ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546 [ 100.991358] ? drm_ioctl+0x1c1/0x3b3 [ 100.994936] ? drm_atomic_set_property+0x92a/0x92a [ 100.999725] drm_ioctl_kernel+0xdc/0x149 [ 101.003648] drm_ioctl+0x27f/0x3b3 [ 101.007051] ? drm_atomic_set_property+0x92a/0x92a [ 101.011842] amdgpu_drm_ioctl+0x49/0x7d [ 101.015679] __se_sys_ioctl+0x7c/0xb8 [ 101.015685] do_syscall_64+0x5f/0xb8 [ 101.015690] ? __irq_exit_rcu+0x34/0x96 [Cómo] Se llama populate_dml_pipes, que utiliza dobles para inicializar. Agregar protección FPU evita el cambio de contexto y la probable pérdida del contexto de VBA, ya que existe una posible contención mientras los registros de depuración de DRM están habilitados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: Restringir el uso de los miembros IRQ del chip GPIO antes de la inicialización Los miembros IRQ del chip GPIO quedan expuestos antes de que se puedan inicializar por completo y esto genera condiciones de ejecución. Se observó un problema de este tipo para la variable gc->irq.domain, a la que se accedía a través de la interfaz I2C en gpiochip_to_irq() antes de que pudiera inicializarse mediante gpiochip_add_irqchip(). Esto provocaba la desreferencia del puntero NULL del kernel. A continuación se muestran los registros de referencia: kernel: Seguimiento de llamadas: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 Para evitar tales escenarios, restrinja el uso de los miembros irq del chip GPIO antes de que se inicialicen por completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: sata_dwc_460ex: Se corrige un fallo debido a que el controlador usa valores de "etiqueta" de libata en varias matrices debido a que la corrección mencionada aumentó ATA_TAG_INTERNAL a 32. Por lo tanto, el valor de SATA_DWC_QCMD_MAX debe tenerlo en cuenta. De lo contrario, el uso de ATA_TAG_INTERNAL causa fallos similares a este, según lo informado por Tice Rex en el foro OpenWrt y reproducido (con símbolos) aquí: | ERROR: Desreferencia de puntero NULL del kernel en 0x00000000 | Dirección de instrucción con error: 0xc03ed4b8 | Vaya: Acceso del kernel a un área incorrecta, firma: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 No contaminado 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 No contaminado (5.4.163) | MSR: 00021000 CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | Rastreo de llamadas: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (no confiable) | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 | [...] Esto se debe a que sata_dwc_dma_xfer_complete() convierte en NULL el próximo vecino "chan" de dma_pending (una estructura *dma_chan) en este caso '32' aquí mismo (línea ~735): > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; Luego, la próxima vez que se emite un dma; dma_dwc_xfer_setup() pasa el hsdevp->chan convertido en NULL a dmaengine_slave_config() que luego causa el bloqueo. Con este parche, SATA_DWC_QCMD_MAX ahora está configurado en ATA_MAX_QUEUE + 1. Esto evita el OOB. Pero tenga en cuenta que hubo una discusión valiosa sobre qué son ATA_TAG_INTERNAL y ATA_MAX_QUEUE. Y por qué no debería haber un tamaño de cola "falso" de 33 comandos. Idealmente, el controlador dw debería tener en cuenta ATA_TAG_INTERNAL. En palabras de Damien Le Moal: "... después de observar el controlador, es un cambio más grande que simplemente falsificar una "etiqueta" número 33 que, de hecho, no es una etiqueta de comando en absoluto". Enlace de error: https://github.com/openwrt/openwrt/issues/9505

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3: Corregir sondeo de GICR_CTLR.RWP Resulta que nuestro sondeo de RWP es totalmente erróneo al comprobarlo en los redistribuidores, ya que probamos el índice de bits del *distribuidor*, mientras que es un número de bit diferente en los RD... Uy, buu. Esto es vergonzoso. No solo porque es incorrecto, sino también porque tardaron *8 años* en darse cuenta del error... Simplemente arreglen la maldita cosa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corregir el desbordamiento de reserva de qgroup del límite de qgroup Usamos extended_changeset->bytes_changed en qgroup_reserve_data() para registrar cuántos bytes configuramos para el estado EXTENT_QGROUP_RESERVED. Actualmente, bytes_changed está configurado como "unsigned int" y se desbordará si intentamos hacer falocación en un rango mayor a 4 GiB. El resultado es que reservamos menos bytes y eventualmente rompemos el límite de qgroup. A diferencia de la escritura directa/en búfer regular, que utilizamos un conjunto de cambios para cada extensión ordenada, que nunca puede ser mayor a 256M. Para falocación, utilizamos un conjunto de cambios para todo el rango, por lo tanto, ya no respeta el límite de 256M por extensión y causó el problema. El siguiente ejemplo de secuencia de comandos de prueba reproduce el problema: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Establezca el límite de qgroup en 2 GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Intente realizar la operación de fallocate de un archivo de 3 GiB. Esto debería fallar. echo echo "Intente realizar la operación de fallocate de un archivo de 3 GiB..." fallocate -l 3G $MNT/3G.file # Intente realizar la operación de fallocate de un archivo de 5 GiB. echo echo "Intente realizar la operación de fallocate de un archivo de 5 GiB..." fallocate -l 5G $MNT/5G.file # Vea que rompemos el límite de qgroup. echo sync btrfs qgroup show -r $MNT umount $MNT Al ejecutar la prueba: $ ./qgroup-overflow.sh (...) Intenta fallar un archivo de 3 GiB... fallocate: fallocate falló: Cuota de disco excedida Intenta fallar un archivo de 5 GiB... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Dado que no tenemos control sobre cómo se usa bytes_changed, es mejor configurarlo en u64.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: arfs: corregir use-after-free al liberar @rx_cpu_rmap Los bots de prueba de CI activaron el siguiente splat: [ 718.203054] ERROR: KASAN: use-after-free en free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Lectura de tamaño 4 en la dirección ffff8881bd127e00 por la tarea sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: cargado Tainted: GSW IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware nombre: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Seguimiento de llamadas: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? informe_kasan.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [hielo] [ 718.260174] ice_remove_arfs+0x5f/0x70 [hielo] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [hielo] [ 718.267419] ice_rebuild+0x39c/0xb60 [hielo] [ 718.270974] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Asignado por la tarea 690: [ 718.433497] Liberado por la tarea 20834: [ 718.495688] Última creación de trabajo potencialmente relacionada: [ 718.568966] La dirección con errores pertenece al objeto en ffff8881bd127e00 que pertenece a la caché kmalloc-96 de tamaño 96 [ 718.574085] La dirección con errores se encuentra a 0 bytes dentro de la región de 96 bytes [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] La dirección con errores pertenece a la página: [ 718.598905] Estado de la memoria alrededor de la dirección con errores: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc Esto se debe a que free_irq_cpu_rmap() siempre se llama *después* de (devm_)free_irq() y, por lo tanto, intenta funcionar. con descripciones IRQ ya liberadas. Por ejemplo, al reiniciar el dispositivo, el controlador libera el rmap justo antes de asignar uno nuevo (el símbolo de arriba). Haga que la creación y liberación de rmap sean simétricas con las llamadas {request,free}_irq(), es decir, hágalo en ifup/ifdown en lugar de en la prueba/eliminación/reanudación del dispositivo. Estas operaciones se pueden realizar independientemente de la configuración aRFS del dispositivo real. Además, asegúrese de que ice_vsi_free_irq() borre los notificadores de afinidad IRQ solo cuando aRFS esté deshabilitado; de lo contrario, el rmap de la CPU establece y borra los suyos propios y no se deben tocar manualmente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: nci: agregar flush_workqueue para evitar uaf Nuestro detector encontró un error de uso simultáneo después de la liberación al desconectar un dispositivo NCI. La razón principal de este error es la programación inesperada entre el mecanismo de retraso utilizado (temporizador y cola de trabajo). La ejecución se puede demostrar a continuación: Hilo-1 Hilo-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Trabajador nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] En resumen, la rutina de limpieza pensó que el cmd_timer ya había sido separado por [1] pero el mod_timer puede volver a unir el temporizador [2], incluso si ya está liberado [3], lo que da como resultado UAF. Este UAF es fácil de activar, el seguimiento de fallas por POC es como el siguiente [66.703713] ======================================================================= [66.703974] ERROR: KASAN: use-after-free en enqueue_timer+0x448/0x490 [66.703974] Escritura de tamaño 8 en la dirección ffff888009fb7058 por la tarea kworker/u4:1/33 [66.703974] [66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 No contaminado 5.18.0-rc2 #5 [ 66.703974] Cola de trabajo: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Rastreo de llamadas: [ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] [ 66.703974] [ 66.703974] Asignado por la tarea 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] Liberado por la tarea 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Se ha corregido la desreferencia de puntero NULL en smc_pnet_find_ib(). Se llamaba a dev_name() con dev.parent como argumento, pero sin comprobarlo antes. Se soluciona comprobando el puntero antes de llamar a dev_name().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: stmmac: corregir la función altr_tse_pcs al usar un enlace fijo Al usar un enlace fijo, el controlador altr_tse_pcs se bloquea debido a la desreferencia de puntero nulo ya que no se proporciona ningún phy_device a la función tse_pcs_fix_mac_speed. Solucione esto agregando una verificación para phy_dev antes de llamar a la función tse_pcs_fix_mac_speed(). También limpie un poco la función tse_pcs_fix_mac_speed. No es necesario verificar splitter_base y sgmii_adapter_base porque el controlador fallará si estas 2 variables no se derivan del árbol de dispositivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige el error KASAN slab-out-of-bounds en cachefiles_set_volume_xattr. Usa la longitud real de los datos de coherencia del volumen al configurar xattr para evitar el siguiente informe KASAN. ERROR: KASAN: slab-out-of-bounds en cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] Escritura de tamaño 4 en la dirección ffff888101e02af4 por la tarea kworker/6:0/1347 CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: cargado No contaminado 5.18.0-rc1-nfs-fscache-netfs+ #13 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 Cola de trabajo: eventos fscache_create_volume_work [fscache] Seguimiento de llamadas: dump_stack_lvl+0x45/0x5a print_report.cold+0x5e/0x5db ? __lock_text_start+0x8/0x8 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_report+0xab/0x120 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_check_range+0xf5/0x1d0 memcpy+0x39/0x60 cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] cachefiles_acquire_volume+0x2be/0x500 [cachefiles] ? __cachefiles_free_volume+0x90/0x90 [cachefiles] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 ? process_one_work+0x6a0/0x6a0 kthread+0x16c/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Asignado por la tarea 1347: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 cachefiles_set_volume_xattr+0x76/0x350 [archivos de caché] cachefiles_acquire_volume+0x2be/0x500 [archivos de caché] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 kthread+0x16c/0x1a0 ret_from_fork+0x22/0x30 La dirección con errores pertenece a el objeto en ffff888101e02af0 que pertenece al caché kmalloc-8 de tamaño 8 La dirección con errores se encuentra 4 bytes dentro de la región de 8 bytes [ffff888101e02af0, ffff888101e02af8) La dirección con errores pertenece a la página física: page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02 flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280 raw: 0000000000000000 0000000080660066 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888101e02980: FC 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC ffff888101e02a00: 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC 00 >ffff888101e02a80: FC FC FC FC 00 FC FC fc fc 00 fc fc fc fc 04 fc ^ ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc =====================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Arreglar la clase de seguimiento svc_deferred_event Arreglar un fallo de desreferencia NULL que ocurre cuando se aplaza un svc_rqst mientras el subsistema de seguimiento sunrpc está habilitado. svc_revisit() establece dr->xprt en NULL, por lo que no se puede confiar en él en el punto de seguimiento para proporcionar la dirección del control remoto. Desafortunadamente, no podemos revertir el trozo "svc_deferred_class" en el commit ece200ddd54b ("sunrpc: Guardar la dirección de presentación remota en svc_xprt para eventos de seguimiento") porque ahora hay una comprobación específica de especificadores de formato de evento para desreferencias inseguras. La advertencia que emite la comprobación es: el evento svc_defer_recv tiene una desreferencia insegura del argumento 1 Un especificador de formato "%pISpc" con un "struct sockaddr *" está marcado por esta comprobación. En su lugar, adopte el enfoque de fuerza bruta utilizado por el punto de seguimiento svcrdma_qp_error. Convierta el campo dr::addr en una dirección de presentación en el brazo TP_fast_assign() del evento de seguimiento y almacénelo como una cadena. Esta corrección se puede implementar en kernels estables. Mientras tanto, el commit c6ced22997ad ("seguimiento: Actualizar la comprobación de impresión fmt para manejar la nueva macro __get_sockaddr()") ahora está en v5.18, por lo que esta corrección complicada se puede reemplazar con __sockaddr() y similares correctamente durante la ventana de fusión de v5.19.