Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: neighbor: Se corrigió null-ptr-deref en neigh_flush_dev(). El robot de pruebas del kernel reportó null-ptr-deref en neigh_flush_dev(). [0] La confirmación citada introdujo una lista de vecinos por netdev y convirtió neigh_flush_dev() para usarla en lugar de la tabla hash global. Un aspecto que pasamos por alto es que neigh_table_clear() llama a neigh_ifdown() con NULL dev. Restablezcamos la iteración de la tabla hash. Tenga en cuenta que el módulo IPv6 ya no se puede descargar, por lo que neigh_table_clear() solo se llama cuando IPv6 no se inicializa, lo cual es improbable. [0]: IPv6: Intento de anular el registro del protocolo permanente 136 IPv6: Intento de anular el registro del protocolo permanente 17 Ups: fallo de protección general, probablemente para la dirección no canónica 0xdffffc00000001a0: 0000 [#1] SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000d00-0x0000000000000d07] CPU: 1 UID: 0 PID: 1 Comm: systemd Contaminado: GT 6.12.0-rc6-01246-gf7f52738637f #1 Contaminado: [T]=RANDSTRUCT Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 RIP: 0010:neigh_flush_dev.llvm.6395807810224103582+0x52/0x570 Código: c1 e8 03 42 8a 04 38 84 c0 0f 85 15 05 00 00 31 c0 41 83 3e 0a 0f 94 c0 48 8d 1c c3 48 81 c3 f8 0c 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 df e8 f7 49 93 fe 4c 8b 3b 4d 85 y siguientes 0f RSP: 0000:ffff88810026f408 EFLAGS: 00010206 RAX: 00000000000001a0 RBX: 00000000000000d00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0631640 RBP: ffff88810026f470 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: fffffffc0625250 R14: fffffffc0631640 R15: dffffc0000000000 FS: 00007f575cb83940(0000) GS:ffff8883aee00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f575db40008 CR3: 00000002bf936000 CR4: 000000000000406f0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: __neigh_ifdown.llvm.6395807810224103582+0x44/0x390 neigh_table_clear+0xb1/0x268 ndisc_cleanup+0x21/0x38 [ipv6] init_module+0x2f5/0x468 [ipv6] do_one_initcall+0x1ba/0x628 do_init_module+0x21a/0x530 load_module+0x2550/0x2ea0 __se_sys_finit_module+0x3d2/0x620 __x64_sys_finit_module+0x76/0x88 x64_sys_call+0x7ff/0xde8 do_syscall_64+0xfb/0x1e8 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f575d6f2719 Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 06 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007fff82a2a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000557827b45310 RCX: 00007f575d6f2719 RDX: 0000000000000000 RSI: 00007f575d584efd RDI: 0000000000000004 RBP: 00007f575d584efd R08: 0000000000000000 R09: 0000557827b47b00 R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000020000 R13: 0000000000000000 R14: 0000557827b470e0 R15: 00007f575dbb4270 Módulos vinculados en: ipv6(+)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Eliminar secpath de skb si no se encuentra el estado xfrm El hardware devuelve un identificador único para el estado xfrm de un paquete descifrado, este estado se busca en un xarray. Sin embargo, el estado podría haberse liberado en el momento de esta búsqueda. Actualmente, si no se encuentra el estado, solo se incrementa un contador. La extensión secpath (sp) en skb no se elimina, lo que hace que sp->len se convierta en 0. Posteriormente, funciones como __xfrm_policy_check() intentan acceder a campos como xfrm_input_state(skb)->xso.type (que desreferencia sp->xvec[sp->len - 1]) sin validar primero sp->len. Esto provoca un fallo al desreferenciar un puntero de estado no válido. Este parche evita el fallo eliminando explícitamente la extensión secpath de skb si no se encuentra el estado xfrm después del descifrado del hardware. Esto garantiza que las funciones posteriores no operen en un secpath de longitud cero. ERROR: no se puede manejar el error de página para la dirección: ffffffff000002c8 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 No contaminado 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NINGUNO Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Código: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 00000000000000002 RDI: 00000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazo de acceso más estrecho a campos de puntero ctx. El siguiente programa BPF, simplificado a partir de una reproducción de syzkaller, genera una advertencia del kernel: r0 = *(u8 *)(r1 + 169); exit; Con el campo de puntero sk en el desplazamiento 168 en __sk_buff. Este acceso se detecta como una lectura más estrecha en bpf_skb_is_valid_access porque no coincide con offsetof(struct __sk_buff, sk). Por lo tanto, se permite y posteriormente procede a bpf_convert_ctx_access. Tenga en cuenta que para el caso "is_narrower_load" en convert_ctx_accesses(), insn->off está alineado, por lo que cnt puede no ser 0 porque coincide con offsetof(struct __sk_buff, sk) en bpf_convert_ctx_access. Sin embargo, el tamaño objetivo permanece en 0 y el verificador genera una advertencia del kernel: error del verificador: error durante la conversión de acceso a ctx(1). Este parche corrige este error para devolver un error correcto de "acceso a bpf_context no válido off=X size=Y" en la instrucción de carga. El mismo problema afecta a varios campos en las estructuras de contexto que permiten acceso restringido. Algunos campos no afectados (para sk_msg, sk_lookup y sockopt) también se modificaron para usar bpf_ctx_range_ptr por consistencia. Tenga en cuenta que este fallo de syzkaller se reportó en el enlace "Cierres" a continuación, que solía referirse a un error diferente, corregido en el commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions in insn_def_regno()"). Debido a que syzbot confundió de alguna manera los dos errores, el nuevo fallo y la reproducción no se reportaron a la lista de correo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: hci_devcd_dump: corrige fuera de los límites mediante dev_coredumpv Actualmente, tanto dev_coredumpv como skb_put_data en hci_devcd_dump usan hdev->dump.head. Sin embargo, dev_coredumpv puede liberar el búfer. De la documentación de dev_coredumpm_timeout, que es utilizada por dev_coredumpv: > Crea un nuevo volcado de memoria del dispositivo para el dispositivo dado. Si aún no se ha leído uno anterior, se descarta el nuevo volcado de memoria. La vida útil de los datos está determinada por el marco de volcado de memoria del dispositivo y cuando ya no se necesitan, se llamará a la función @free para liberar los datos. Si el espacio de usuario aún no ha leído los datos, dev_coredumpv descartará el nuevo búfer, liberando hdev->dump.head. Esto genera un error vmalloc-out-of-bounds cuando skb_put_data intenta acceder a hdev->dump.head. Un informe de fallos de syzbot ilustra esto: ======================================================================= ERROR: KASAN: vmalloc-out-of-bounds in skb_put_data include/linux/skbuff.h:2752 [inline] BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844 CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: hci0 hci_devcd_timeout Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105 skb_put_data include/linux/skbuff.h:2752 [inline] hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258 hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping Memory state around the buggy address: ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Para evitar este problema, reordene dev_coredumpv para que se llame después de skb_put_data que no libera los datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el uso de inodo use after free en ext4_end_io_rsv_work() En ext4_io_end_defer_completion(), se comprueba si io_end->list_vec está vacío para evitar añadir un io_end que no requiere conversión a i_rsv_conversion_list, lo que a su vez impide iniciar un trabajador innecesario. También se añade una comprobación ext4_emergency_state() para evitar intentar abortar el diario en un estado de emergencia. Además, ext4_put_io_end_defer() se refactoriza para llamar a ext4_io_end_defer_completion() directamente en lugar de estar en código abierto. Esto también impide iniciar un trabajador innecesario cuando EXT4_IO_END_FAILED está configurado pero data_err=abort no está habilitado. Esto garantiza que la comprobación en ext4_put_io_end_defer() sea coherente con la comprobación en ext4_end_bio(). De lo contrario, podríamos agregar un io_end a i_rsv_conversion_list y luego llamar a ext4_finish_bio(), después de lo cual el inodo podría liberarse antes de que se llame a ext4_end_io_rsv_work(), lo que desencadenaría un problema de use-after-free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige la doble destrucción de rsv_qp. rsv_qp puede sufrir una doble destrucción en el flujo de errores, primero en free_mr_init() y luego en hns_roce_exit(). Se corrige trasladando la llamada a free_mr_init() a hns_roce_v2_init(). Corrupción de list_del, ffff589732eb9b50->el siguiente es LIST_POISON1 (dead000000000100) ADVERTENCIA: CPU: 8 PID: 1047115 en lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Rastreo de llamadas: __list_del_entry_valid+0x148/0x240 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2] hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2] hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2] free_mr_exit+0x6c/0x120 [hns_roce_hw_v2] hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2] hns_roce_exit+0x118/0x350 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2] hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2] hclge_notify_roce_client+0x6c/0x160 [hclge] hclge_reset_rebuild+0x150/0x5c0 [hclge] hclge_reset+0x10c/0x140 [hclge] hclge_reset_subtask+0x80/0x104 [hclge] hclge_reset_service_task+0x168/0x3ac [hclge] hclge_service_task+0x50/0x100 [hclge] process_one_work+0x250/0x9a0 worker_thread+0x324/0x990 kthread+0x190/0x210 ret_from_fork+0x10/0x18

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: Arregla pd UAF de una vez por todas Hay una condición de ejecución/UAF en padata_reorder que se remonta a la confirmación inicial. Se toma un recuento de referencias al inicio del proceso en padata_do_parallel y se libera al final en padata_serial_worker. Este recuento de referencias es (y solo es) necesario para que padata_replace funcione correctamente. Si nunca se llama a padata_replace, no hay problema. En la función padata_reorder que sirve como núcleo de padata, tan pronto como padata se agrega a queue->serial.list y se libera el bloqueo de giro asociado, ese padata puede procesarse y el recuento de referencias en pd desaparecería. Arregla esto obteniendo el siguiente padata antes de que se libere el bloqueo squeue->serial. Para que esto sea posible, simplifica padata_reorder llamándolo solo una vez que llega el siguiente padata.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: media: atomisp: Corrección del desbordamiento del búfer de pila en gmin_get_var_int() Cuando gmin_get_config_var() llama a efi.get_variable() y la variable EFI es mayor que el tamaño de búfer esperado, se combinan dos comportamientos para crear un desbordamiento del búfer de pila: 1. gmin_get_config_var() no devuelve el código de error correcto cuando efi.get_variable() falla. Devuelve el valor 'ret' obsoleto de operaciones anteriores en lugar de indicar el fallo de EFI. 2. Cuando efi.get_variable() devuelve EFI_BUFFER_TOO_SMALL, actualiza *out_len al tamaño de búfer requerido, pero no escribe datos en el búfer de salida. Sin embargo, debido al error n.º 1, gmin_get_var_int() cree que la llamada tuvo éxito. El llamador gmin_get_var_int() realiza entonces: - Asigna val[CFG_VAR_NAME_MAX + 1] (65 bytes) en la pila - Llama a gmin_get_config_var(dev, is_gmin, var, val, &len) con len=64 - Si la variable EFI es >64 bytes, efi.get_variable() establece len=required_size - Debido al error #1, piensa que la llamada tuvo éxito con len=required_size - Ejecuta val[len] = 0, escribiendo más allá del final del búfer de pila de 65 bytes Esto crea un desbordamiento del búfer de pila cuando las variables EFI son mayores de 64 bytes. Dado que las variables EFI pueden ser controladas por el firmware o la configuración del sistema, esto podría ser potencialmente explotado para la ejecución de código. Corrija el error devolviendo los códigos de error adecuados de gmin_get_config_var() basados en el estado de EFI en lugar del valor 'ret' obsoleto. La función gmin_get_var_int() se llama durante la inicialización del dispositivo para la configuración del sensor de la cámara en las plataformas Intel Bay Trail y Cherry Trail utilizando la pila de cámara atomisp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección del valor no inicializado de KMSAN en el uso de extent_info. KMSAN informó del uso de un valor no inicializado en `__is_extent_mergeable()` y `__is_back_mergeable()` mediante la ruta de lectura del árbol de extensiones. La causa principal es que `get_read_extent_info()` solo inicializa tres campos (`fofs`, `blk`, `len`) de `struct extent_info`, dejando los campos restantes sin inicializar. Esto provoca un comportamiento indefinido al acceder a dichos campos posteriormente, especialmente durante la fusión de extensiones. Para solucionarlo, inicialice a cero la estructura `extent_info` antes de rellenarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: ccp - Se corrige el fallo al revincular el dispositivo ccp para ccp.ko Cuando CONFIG_CRYPTO_DEV_CCP_DEBUGFS está habilitado, revincular el dispositivo ccp provoca el siguiente fallo: $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind [ 204.976930] ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000098 [ 204.978026] #PF: acceso de escritura del supervisor en modo kernel [ 204.979126] #PF: error_code(0x0002) - página no presente [ 204.980226] PGD 0 P4D 0 [ 204.981317] Ups: Ups: 0002 [#1] SMP NOPTI ... [ 204.997852] Seguimiento de llamadas: [ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0 [ 205.001533] debugfs_create_dir+0x1f/0x170 [ 205.002769] ? srso_return_thunk+0x5/0x5f [ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp] [ 205.005241] ccp5_init+0x8b2/0x960 [ccp] [ 205.006469] ccp_dev_init+0xd4/0x150 [ccp] [ 205.007709] sp_init+0x5f/0x80 [ccp] [ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp] [ 205.010165] ? srso_return_thunk+0x5/0x5f [ 205.011376] local_pci_probe+0x4f/0xb0 [ 205.012584] pci_device_probe+0xdb/0x230 [ 205.013810] really_probe+0xed/0x380 [ 205.015024] __driver_probe_device+0x7e/0x160 [ 205.016240] device_driver_attach+0x2f/0x60 [ 205.017457] bind_store+0x7c/0xb0 [ 205.018663] drv_attr_store+0x28/0x40 [ 205.019868] sysfs_kf_write+0x5f/0x70 [ 205.021065] kernfs_fop_write_iter+0x145/0x1d0 [ 205.022267] vfs_write+0x308/0x440 [ 205.023453] ksys_write+0x6d/0xe0 [ 205.024616] __x64_sys_write+0x1e/0x30 [ 205.025778] x64_sys_call+0x16ba/0x2150 [ 205.026942] do_syscall_64+0x56/0x1e0 [ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 205.029276] RIP: 0033:0x7fbc36f10104 [ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 Este parche establece ccp_debugfs_dir como NULL tras destruirlo en ccp5_debugfs_destroy, lo que permite recrear la entrada del directorio al reenlazar el dispositivo ccp. Probado en AMD Ryzen 7 1700X.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: xilinx: vcu: anular el registro de pll_post solo si está registrado correctamente Si falla el registro de pll_post, se establecerá en NULL o ERR, y su anulación fallará con el siguiente seguimiento de llamada: No se puede controlar la desreferencia del puntero NULL del kernel en la dirección virtual 008 pc: clk_hw_unregister+0xc/0x20 lr: clk_hw_unregister_fixed_factor+0x18/0x30 sp: ffff800011923850 ... Seguimiento de llamada: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cs42l43: La entrada de propiedad debe ser una matriz con terminación nula. El nodo de software no especifica un número de entradas de propiedad, por lo que la matriz debe terminar en nulo. Si no está terminada, esto puede provocar un fallo en el controlador del amplificador cs35l56, ya que el análisis del nodo se desvía del final de la matriz hacia una memoria desconocida.