Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: Se corrigió el manejo de dispositivos incorrectos durante el bond netevent. La implementación actual del controlador bond netevent solo verifica si el netdev manejado es el representante VF y falta una verificación si el representante VF está activado. el mismo dispositivo físico del vínculo que maneja el evento neto. Para solucionarlo, agregue la verificación que falta y optimice la verificación si netdev es el representante de VF para que no acceda a datos privados no inicializados y se bloquee. ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000036c PGD 0 P4D 0 Ups: 0000 [#1] Cola de trabajo SMP NOPTI: eth3bond0 bond_mii_monitor [unión] RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core] RSP: 018:ffff88812d69fd60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000 RDX: ffff88812d69fe10 RSI: 0000000000000001b RDI: ffff8881cf800880 RBP: ffff8881 cf800000 R08: 00000445cabccf2b R09: 0000000000000008 R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10 R13: 00000000ffffffe R 14: ffff88820c0f9000 R15: 0000000000000000 FS: 0000000000000000(0000 ) GS:ffff88846fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036c CR3: 0000000103d80 006 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 000000000000400 Llamar Seguimiento: mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core] mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core] mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core] raw_notifier_call_chain+0x41/0x60 _notifiers_info+0x34/0x80 netdev_lower_state_changed+0x4e/0xa0 bond_mii_monitor+0x56b/0x640 [vinculación] proceso_one_work +0x1b9/0x390 hilo_trabajador+0x4d/0x3d0 ? hilo_rescate+0x350/0x350 khilo+0x124/0x150 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el desplazamiento incorrecto en bio_truncate() bio_truncate() borra el búfer fuera del último bloque de bdev, sin embargo, el bio_truncate() actual está usando el desplazamiento de página incorrecto. Entonces puede devolver los datos no inicializados. Esto sucedió cuando tanto el FS truncado/corrupto como el espacio de usuario (a través de bdev) intentaban leer lo último de bdev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Evite el desbordamiento de campos memcpy() En preparación para FORTIFY_SOURCE, se realizan comprobaciones de los límites de campos en tiempo de compilación y tiempo de ejecución para memcpy(), memmove() y memset( ), evite escribir intencionalmente en campos vecinos. Utilice matrices flexibles en lugar de matrices de elementos cero (que parecen estar siempre desbordadas) y divida el campo cruzado memcpy() en dos mitades que el compilador pueda verificar adecuadamente los límites. Estábamos haciendo: #define ETH_HLEN 14 #define VLAN_HLEN 4... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... estructura mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->datos; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); El objetivo es wqe->eth.inline_hdr.start (que el compilador considera que tiene un tamaño de 2 bytes), pero copia 18, con la intención de escribir a lo largo del inicio (en realidad, vlan_tci, 2 bytes). Los 16 bytes restantes se escriben en wqe->data[0], cubriendo byte_count (4 bytes), lkey (4 bytes) y addr (8 bytes). estructura mlx5e_tx_wqe { estructura mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg datos[]; /* 32 0 */ /* tamaño: 32, líneas de caché: 1, miembros: 3 */ /* última línea de caché: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ unión { estructura { __be16 sz; /* 12 2 */ u8 inicio[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 tipo; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insertar; /* 12 4 */ __be32 remolque; /* 12 4 */ }; /* 12 4 */ /* tamaño: 16, líneas de caché: 1, miembros: 9 */ /* última línea de caché: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 dirección; /* 8 8 */ /* tamaño: 16, líneas de caché: 1, miembros: 3 */ /* última línea de caché: 16 bytes */ }; Entonces, divida memcpy() para que el compilador pueda razonar sobre los tamaños del búfer. "pahole" no muestra cambios de tamaño ni de compensación de miembros en la estructura mlx5e_tx_wqe ni en la estructura mlx5e_umr_wqe. "objdump -d" no muestra cambios significativos en el código objeto (es decir, solo diferencias y optimizaciones inducidas por el número de línea de origen).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/ucma: protege mc durante las salidas simultáneas de multidifusión. Revierta parcialmente la confirmación mencionada en la línea Correcciones para asegurarse de que la asignación y el borrado de la estructura de multidifusión estén bloqueados. ERROR: KASAN: use-after-free en ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [en línea] ERROR: KASAN: use-after-free en ucma_destroy_private_ctx+0x914/0xb70 drivers/infiniband/core/ucma.c: 579 Lectura de tamaño 8 en la dirección ffff88801bb74b00 mediante la tarea syz-executor.1/25529 CPU: 0 PID: 25529 Comm: syz-executor.1 No contaminado 5.16.0-rc7-syzkaller #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan /report.c:247 __kasan_report mm/kasan/report.c:433 [en línea] kasan_report.cold+0x83/0xdf mm/kasan/report.c:450 ucma_cleanup_multicast drivers/infiniband/core/ucma.c:491 [en línea] ucma_destroy_private_ctx+0x914/0xb70 controladores/infiniband/core/ucma.c:579 ucma_destroy_id+0x1e6/0x280 controladores/infiniband/core/ucma.c:614 ucma_write+0x25c/0x350 controladores/infiniband/core/ucma.c:1732 vfs_write+ 0x28e/0xae0 fs/read_write.c:588 ksys_write+0x1ee/0x250 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common. c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae Actualmente, la búsqueda de xarray puede tocar un mc que se libera simultáneamente ya que xa_for_each() no está rodeado por ningún candado. En lugar de mantener el bloqueo durante un escaneo completo, manténgalo solo para los elementos afectados, que generalmente son una lista vacía.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: Evite consumir un valor esr obsoleto cuando ocurre un SError Cuando ocurre cualquier excepción que no sea una IRQ, la CPU actualiza el registro ESR_EL2 con el síndrome de excepción. Un SError también puede quedar pendiente y KVM lo sincronizará. KVM anota el tipo de excepción y si se sincronizó un SError en exit_code. Cuando ocurre una excepción distinta a una IRQ, fixup_guest_exit() actualiza vcpu->arch.fault.esr_el2 desde el registro de hardware. Cuando se sincroniza un SError, el valor de vcpu esr se utiliza para determinar si la excepción se debió a un HVC. Si es así, ELR_EL2 retrocede una instrucción. Esto es para que KVM pueda procesar el SError primero y volver a ejecutar el HVC si el invitado sobrevive al SError. Pero si una IRQ sincroniza un SError, el valor esr de la vcpu está obsoleto. Si la excepción anterior no IRQ era un HVC, KVM dañará ELR_EL2, lo que provocará que se ejecute dos veces una instrucción invitada no relacionada. Verifique ARM_EXCEPTION_CODE() antes de jugar con ELR_EL2, las IRQ no actualizan este registro, por lo que no es necesario verificarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/hfi1: corrige el pánico de inicio temprano de AIP Una falla temprana en hfi1_ipoib_setup_rn() puede provocar el siguiente pánico: ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000001b0 PGD 0 P4D 0 Vaya: 0002 [#1] Cola de trabajo SMP NOPTI: eventos work_for_cpu_fn RIP: 0010:try_to_grab_pending+0x2b/0x140 Código: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 4 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c RSP 0018:ffffb6b3cf7 cfa48 EFLAGS: 00010046 RAX: 0000000000000246 RBX: 00000000000001b0 RCX: 0000000000000000 RDX: 0000000000000246 RSI: 00000000000000000 RDI: 00000000000001b0 RBP: ffffb6b3cf7cfa70 R08: 0000000000000f09 R09: 0000000000000001 R10: 0000000000000000 R11: 00000000000000001 R12: 0000000000000000 R13: b6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690 FS: 0000000000000000(0000) GS :ffff8a527f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000001b0 CR3: CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000 0000000000400 PKRU: 55555554 Seguimiento de llamadas: __cancel_work_timer+0x42/0x190 ? dev_printk_emit+0x4e/0x70 iowait_cancel_work+0x15/0x30 [hfi1] hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1] ? dev_err+0x6c/0x90 hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1] hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1] rdma_init_netdev+0x5a/0x80 [ib_core] ? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1] ipoib_intf_init+0x6c/0x350 [ib_ipoib] ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib] ipoib_add_one+0xbe/0x300 [ib_ipoib] 0x1a0 [ib_core] enable_device_and_get+0xdc/0x1d0 [ib_core] ib_register_device+ 0x572/0x6b0 [ib_core] rvt_register_device+0x11b/0x220 [rdmavt] hfi1_register_ib_device+0x6b4/0x770 [hfi1] do_init_one.isra.20+0x3e3/0x680 [hfi1] local_pci_probe+0x41/0x90 cpu_fn+0x16/0x20 proceso_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 trabajador_thread+0x1cf/0x390? create_worker+0x1a0/0x1a0 kthread+0x116/0x130? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 El pánico ocurre en hfi1_ipoib_txreq_deinit() porque hay una deref NULL cuando se llama a hfi1_ipoib_netdev_dtor() en este caso de error. hfi1_ipoib_txreq_init() y hfi1_ipoib_rxq_init() se desenrollan automáticamente, así que corrija ajustando las rutas de error en consecuencia. Otros cambios: - hfi1_ipoib_free_rdma_netdev() se elimina incluyendo free_netdev() ya que el código central de netdev elimina las llamadas free_netdev() - El cambio a las entradas aceleradas se mueve a la ruta de éxito.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/hfi1: Corrija el pánico con ipoib send_queue_size más grande Cuando ipoib send_queue_size aumenta respecto del valor predeterminado, ocurre el siguiente pánico: RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1] Código: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 83 8 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0 RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286 RAX: 00000000000008000 RBX: ffffc9000aa0f000 RCX: 000000000000000f RDX: 00000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff88810ff08000 R08: ffff88889476d900 R09: 0000000000000101 R10: 0000000000000000 R11: ffffc90006590ff8 R12: 0000000000000200 R13: ffffc9000798fba8 R14: 0000000000000000 R15: 00000000000001 FS: 00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR 2: ffffc9000aa0f118 CR3 : 0000000889c84001 CR4: 00000000001706e0 Seguimiento de llamadas: hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1] hfi1_ipoib_dev_stop+0x18/0x80 [hfi1] [ib_ipoib] ipoib_stop+0x48/0xc0 [ib_ipoib] __dev_close_many+0x9e/0x110 __dev_change_flags+ 0xd9/0x210 dev_change_flags+0x21/0x60 do_setlink+0x31c/0x10f0? __nla_validate_parse+0x12d/0x1a0 ? __nla_parse+0x21/0x30? inet6_validate_link_af+0x5e/0xf0? cpumask_next+0x1f/0x20 ? __snmp6_fill_stats64.isra.53+0xbb/0x140 ? __nla_validate_parse+0x47/0x1a0 __rtnl_newlink+0x530/0x910 ? pskb_expand_head+0x73/0x300? __kmalloc_node_track_caller+0x109/0x280 ? __nla_put+0xc/0x20 ? cpumask_next_and+0x20/0x30? update_sd_lb_stats.constprop.144+0xd3/0x820? _raw_spin_unlock_irqrestore+0x25/0x37? __wake_up_common_lock+0x87/0xc0? kmem_cache_alloc_trace+0x3d/0x3d0 rtnl_newlink+0x43/0x60 El problema ocurre cuando el cambio que debería haber sido una función del tamaño del elemento txq usó por error el tamaño del anillo. Arreglar usando el tamaño del elemento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: heaps: repara un posible gadget de Spectre v1. Parece que nr podría ser un gadget de Spectre v1, ya que lo proporciona un usuario y se utiliza como índice de matriz. Evite que el contenido de la memoria del kernel se filtre al espacio de usuario mediante ejecución especulativa utilizando array_index_nospec. [presenta: correcciones agregadas y cc: etiquetas estables]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/kmemleak: evita escanear posibles agujeros enormes. Al usar devm_request_free_mem_region() y devm_memremap_pages() para agregar memoria ZONE_DEVICE, si se solicitaba, el pfn final de la región de memoria libre era enorme (por ejemplo, 0x400000000), el node_end_pfn() también será enorme (ver move_pfn_range_to_zone()). Por lo tanto, crea un enorme agujero entre node_start_pfn() y node_end_pfn(). Descubrimos que en algunas APU AMD, AMDKFD solicitó una región de memoria libre y creó un agujero enorme. En tal caso, el siguiente fragmento de código simplemente estaba haciendo un bucle test_bit() ocupado en el enorme agujero. for (pfn = start_pfn; pfn < end_pfn; pfn++) { estructura página *página = pfn_to_online_page(pfn); si (!página) continúa; ... } Entonces obtuvimos un bloqueo suave: perro guardián: ERROR: bloqueo suave - ¡CPU#6 bloqueada durante 26 segundos! [bash:1221] CPU: 6 PID: 1221 Comm: bash No contaminado 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Seguimiento de llamadas:? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 Entry_SYSCALL_64_after_hwframe+0x4 4/0xae Hice algunas pruebas con el parche. (1) módulo amdgpu descargado antes del parche: usuario real 0m0.976s 0m0.000s sys 0m0.968s después del parche: usuario real 0m0.981s 0m0.000s sys 0m0.973s (2) módulo amdgpu cargado antes del parche: real 0m35 .365s usuario 0m0.000s sys 0m35.354s después del parche: real 0m1.049s usuario 0m0.000s sys 0m1.042s

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: solucionado por uno en la comprobación de los límites del BIOS. La comprobación de los límites al analizar los scripts de inicio integrados en el BIOS rechaza el acceso al último byte. Esto hace que la inicialización del controlador falle en Apple eMac con GPU GeForce 2 MX, dejando el sistema sin consola funcional. Probablemente esto solo se vea en máquinas OpenFirmware como PowerPC Mac porque la imagen del BIOS proporcionada por OF es solo las partes utilizadas de la ROM, no una potencia de dos bloques leída directamente desde PCI, por lo que las PC siempre tienen bytes vacíos al final que son nunca accedido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: soluciona el punto muerto entre la desactivación de cuota y el trabajador de rescaneo de qgroup. La desactivación de cuota ioctl inicia una transacción antes de esperar a que se complete el trabajador de rescaneo de qgroup. Sin embargo, esta espera puede ser infinita y provocar un punto muerto debido a la dependencia circular entre el ioctl de desactivación de cuota, el trabajador de rescaneo de qgroup y la otra tarea con transacciones como la tarea de reubicación del grupo de bloques. El punto muerto ocurre con los siguientes pasos: 1) La tarea A llama a ioctl para deshabilitar la cuota. Inicia una transacción y espera a que se complete el trabajo de rescaneo de qgroup. 2) La tarea B, como la tarea de reubicación del grupo de bloques, inicia una transacción y se une a la transacción que inició la tarea A. Luego la tarea B se compromete con la transacción. En esta confirmación, la tarea B espera una confirmación de la tarea A. 3) La tarea C, como trabajador de rescaneo de qgroup, inicia su trabajo e inicia una transacción. En el inicio de esta transacción, la tarea C espera a que se complete la transacción que inició la tarea A y confirmó la tarea B. Este punto muerto se encontró con el caso de prueba btrfs/115 de fstests y un dispositivo null_blk zonificado. El caso de prueba habilita y deshabilita la cuota, y la recuperación del grupo de bloques se activó durante la deshabilitación de la cuota por casualidad. El punto muerto también se observó al ejecutar la habilitación y deshabilitación de cuotas en paralelo con el comando 'btrfs balance' en dispositivos null_blk normales. Un informe de ejemplo del punto muerto: [372.469894] INFORMACIÓN: tarea kworker/u16:6:103 bloqueada durante más de 122 segundos. [372.479944] No contaminado 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [372.493898] tarea:kworker/u16:6 estado:D pila: 0 pid: 103 ppid: 2 banderas:0x00004000 [372.503285] Cola de trabajo: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Seguimiento de llamadas: [372.521684] __programación+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] horario+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? terminar_esperar+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054]? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960]? do_raw_spin_lock+0x11e/0x250 [372.627137]? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] Process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081]? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] trabajador_thread+0x59e/0xf90 [372.676172] ? proceso_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] [372.709747] INFORMACIÓN: tarea btrfs-transacti:2347 bloqueada durante más de 123 segundos. [372.729827] No contaminado 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [372.767106] tarea: btrfs-transacti estado: D pila: 0 pid: 2347 ppid: 2 banderas: 0x00004000 [372.787776] Seguimiento de llamadas: [372.801652] [372.812961] __schedule+0xb56/0x4850 [372.83 0011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761]? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] horario+0xe0/0x270 [372.901685] ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ALSA: hda: corrige UAF de los desarrolladores de clase LED al desvincularse. Los dispositivos de clase LED creados por controladores de códec de audio HD se registran a través de devm_led_classdev_register() y se asocian con el audio HD. dispositivo códec. Desafortunadamente, resultó que la versión devres no funciona para este caso; es decir, dado que la liberación del recurso del códec ocurre antes de la cadena de llamadas del desarrollador, desencadena una desreferencia NULL o un UAF para una devolución de llamada obsoleta set_brightness_delay. Para corregir el error, este parche cambia el registro y cancelación del registro del dispositivo de clase LED de forma manual sin devres, manteniendo las instancias en hda_gen_spec.