Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: salida tras fallo de inserción de estado en btrfs_convert_extent_bit(). Si el estado insert_state() falla, devuelve un puntero de error y se llama a extent_io_tree_panic(), lo que activa una llamada a BUG(). Sin embargo, si CONFIG_BUG está deshabilitado (un escenario inusual y exótico), se pasa a la siguiente etapa y se llama a cache_state(), lo que desreferencia el puntero de error, lo que resulta en un acceso no válido a memoria. Por lo tanto, al saltar a la etiqueta "out" después de llamar a extent_io_tree_panic(), se aclara el código, además de abordar el escenario exótico donde CONFIG_BUG está deshabilitado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: drv: netdevsim: no ejecutar napi_complete() desde netpoll. netdevsim es compatible con netpoll. Asegúrese de no ejecutar napi_complete() desde él, ya que podría no estar programado. Breno informa de una advertencia en napi_complete_done(): ADVERTENCIA: CPU: 14 PID: 104 en net/core/dev.c:6592 napi_complete_done+0x2cc/0x560 __napi_poll+0x2d8/0x3a0 handle_softirqs+0x1fe/0x710. Presumiblemente, esto se debe a que netpoll robó el bit SCHED prematuramente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: impide una desreferencia NULL en rtnl_create_link(). Mientras rtnl_create_link() se ejecuta, dev->netdev_ops es NULL. No debemos usar netdev_lock_ops() o corremos el riesgo de una desreferencia NULL si CONFIG_NET_SHAPER está definido. Use netif_set_group() en lugar de dev_set_group(). RIP: 0010:netdev_need_ops_lock include/net/netdev_lock.h:33 [en línea] RIP: 0010:netdev_lock_ops include/net/netdev_lock.h:41 [en línea] RIP: 0010:dev_set_group+0xc0/0x230 net/core/dev_api.c:82 Rastreo de llamadas: rtnl_create_link+0x748/0xd10 net/core/rtnetlink.c:3674 rtnl_newlink_create+0x25c/0xb00 net/core/rtnetlink.c:3813 __rtnl_newlink net/core/rtnetlink.c:3940 [en línea] rtnl_newlink+0x16d6/0x1c70 net/core/rtnetlink.c:4055 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [en línea] netlink_unicast+0x75b/0x8d0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [en línea]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: b53: no habilitar EEE en bcm63xx. Los conmutadores internos BCM63xx no admiten EEE, pero proporcionan múltiples puertos RGMII donde se pueden conectar PHY externos. Si uno de estos PHY admite EEE, podemos intentar habilitar EEE para las MAC, lo que bloquea el sistema al acceder a los registros EEE (inexistentes). Para solucionar esto, verifique si el conmutador admite EEE antes de configurarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fpga: se corrige una posible desreferencia de puntero nulo en fpga_mgr_test_img_load_sgt(). fpga_mgr_test_img_load_sgt() asigna memoria para sgt mediante kunit_kzalloc(), pero no comprueba si la asignación ha fallado. A continuación, pasa sgt a sg_alloc_table(), que a su vez la pasa a __sg_alloc_table(). Esta función llama a memset() en sgt para intentar ponerlo a cero. Si la asignación falla, sgt será nulo y memset activará una desreferencia de puntero nulo. Solucione esto comprobando la asignación con KUNIT_ASSERT_NOT_ERR_OR_NULL().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: qcom-qmp-usb: Se corrige un error de NULL frente a IS_ERR(). La función auxiliar qmp_usb_iomap() actualmente devuelve el resultado sin procesar de devm_ioremap() para asignaciones no exclusivas. Dado que devm_ioremap() puede devolver un puntero NULL y el llamador solo comprueba los punteros de error con IS_ERR(), NULL podría omitir la comprobación y provocar una desreferencia no válida. Corrija el problema comprobando si devm_ioremap() devuelve NULL. Cuando lo hace, qmp_usb_iomap() ahora devuelve un puntero de error mediante IOMEM_ERR_PTR(-ENOMEM), lo que garantiza un manejo de errores seguro y consistente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tipc: corrección de la advertencia de recuento de referencias en tipc_aead_encrypt. syzbot reportó una advertencia de recuento de referencias [1] causada por la llamada a get_net() en un espacio de nombres de red que se está destruyendo (recuento de referencias = 0). Esto ocurre cuando se activa un temporizador de descubrimiento de TIPC durante la limpieza del espacio de nombres de red. La llamada a get_net(), recientemente añadida en el commit e279024617134 ("net/tipc: corrección de la lectura de slab-use-after-free en tipc_aead_encrypt_done"), intenta contener una referencia al espacio de nombres de red. Sin embargo, si el espacio de nombres ya se está destruyendo, su recuento de referencias podría ser cero, lo que genera la advertencia de use-after-free. Reemplace get_net() por perhaps_get_net(), que comprueba de forma segura si el recuento de referencias es distinto de cero antes de incrementarlo. Si el espacio de nombres se está destruyendo, devuelva -ENODEV antes de tiempo, después de liberar la referencia del portador. [1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: jsm: fix NPE durante jsm_uart_port_init No se configuró ningún dispositivo que causó que serial_base_ctrl_add se bloqueara. ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000050 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) No contaminado 6.12.25-amd64 #1 Debian 6.12.25-1 RIP: 0010:serial_base_ctrl_add+0x96/0x120 Rastreo de llamadas: serial_core_register_port+0x1a0/0x580 ? __setup_irq+0x39c/0x660 ? __kmalloc_cache_noprof+0x111/0x310 jsm_uart_port_init+0xe8/0x180 [jsm] jsm_probe_one+0x1f4/0x410 [jsm] local_pci_probe+0x42/0x90 pci_device_probe+0x22f/0x270 really_probe+0xdb/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8c/0xe0 bus_add_driver+0x112/0x1f0 driver_register+0x72/0xd0 jsm_init_module+0x36/0xff0 [jsm] ? __pfx_jsm_init_module+0x10/0x10 [jsm] do_one_initcall+0x58/0x310 do_init_module+0x60/0x230 Probado con la tarjeta Digi Neo PCIe de 8 puertos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: mediatek: eint: Corrección de la desreferencia de puntero no válida para plataformas v1. El commit 3ef9f710efcb ("pinctrl: mediatek: Añadir compatibilidad con EINT para múltiples direcciones") introdujo un acceso al campo 'soc' de struct mtk_pinctrl en mtk_eint_do_init() y, para ello, la inclusión de pinctrl-mtk-common-v2.h. Sin embargo, los controladores pinctrl que dependen del controlador común v1 incluyen pinctrl-mtk-common.h, que proporciona otra definición de struct mtk_pinctrl que no contiene el campo 'soc'. Dado que mtk_eint_do_init() puede ser invocado tanto por controladores v1 como v2, ahora intentará desreferenciar un puntero no válido al invocarlo en plataformas v1. Esto se ha observado en Genio 350 EVK (MT8365), que se bloquea al inicio (la traza del kernel solo se puede ver con earlycon). Para solucionarlo, dado que 'struct mtk_pinctrl' solo era necesario para obtener un 'struct mtk_eint_pin', se debe convertir 'struct mtk_eint_pin' en un parámetro de mtk_eint_do_init() para que quienes lo invoquen deban proporcionarlo, eliminando así la dependencia de mtk_eint_do_init() de cualquier 'struct mtk_pinctrl' en particular.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: No se activa WARN_ON() debido a un commit_overrun. Al leer un búfer asignado a memoria, la página del lector simplemente se intercambia con la última página escrita en el búfer de escritura. Si la página del lector coincide con el búfer de confirmación (el búfer en el que se está escribiendo), se asumía que nunca debería haber omitido eventos. Si lo hace, activa WARN_ON_ONCE(). Sin embargo, existe un escenario donde esto puede ocurrir legítimamente: un commit_overrun. Un commit_overrun ocurre cuando una interrupción adelanta un evento que se está escribiendo en el búfer y luego la interrupción agrega tantos eventos nuevos que llena y envuelve el búfer de nuevo en la confirmación. Cualquier evento nuevo se descartaría y se reportaría como "missed_events". En este caso, la siguiente página a leer es el búfer de confirmación y después del intercambio de la página del lector, la página del lector será el búfer de confirmación, pero esta vez habrá eventos perdidos y esto activa la siguiente advertencia: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780 Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff <0f> 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50 RSP: 0018:ffff888121787dc0 EFLAGS: 00010002 RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49 RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982 R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00 R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008 FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0 Call Trace: ? __pfx_ring_buffer_map_get_reader+0x10/0x10 tracing_buffers_ioctl+0x283/0x370 __x64_sys_ioctl+0x134/0x190 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f95c8de48db Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00 RSP: 002b:00007ffe037ba110 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffe037bb2b0 RCX: 00007f95c8de48db RDX: 0000000000000000 RSI: 0000000000005220 RDI: 0000000000000006 RBP: 00007ffe037ba180 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe037bb6f8 R14: 00007f95c9065000 R15: 00005575c7492c90 irq event stamp: 5080 hardirqs last enabled at (5079): [] _raw_spin_unlock_irqrestore+0x50/0x70 hardirqs last disabled at (5080): [] _raw_spin_lock_irqsave+0x63/0x70 softirqs last enabled at (4182): [] handle_softirqs+0x552/0x710 softirqs last disabled at (4159): [] __irq_exit_rcu+0x107/0x210 ---[ fin del seguimiento 0000000000000000 ]--- Lo anterior se activó al ejecutar un kernel con lockdep y KASAN, así como kmemleak habilitados, y al ejecutar el siguiente comando: # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50 Con perf intercalando muchas interrupciones y trace-cmd habilitando todos los eventos así como el seguimiento de funciones, con lockdep, KASAN y kmemleak habilitados, podría causar una interrupción que interrumpa la escritura de un evento para agregar suficiente evento ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpm: mover tcpm_queue_vdm_unlocked a trabajo asíncrono Anteriormente se agregó una comprobación de estado a tcpm_queue_vdm_unlocked para evitar un interbloqueo donde el controlador de modo alternativo de DisplayPort estaría ejecutando trabajo e intentando agarrar el tcpm_lock mientras que TCPM mantenía el bloqueo e intentaba anular el registro del modo alternativo, bloqueando la llamada cancel_work_sync del controlador del modo alternativo. Debido a que la comprobación de estado no está protegida, hay una pequeña ventana donde el controlador del modo alternativo podría determinar que TCPM está en un estado listo e intentar agarrar el bloqueo mientras TCPM toma el bloqueo y cambia el estado de TCPM a uno que causa el interbloqueo. La pila de llamadas se proporciona a continuación: [110121.667392][ C7] Rastreo de llamadas: [110121.667396][ C7] __switch_to+0x174/0x338 [110121.667406][ C7] __schedule+0x608/0x9f0 [110121.667414][ C7] schedule+0x7c/0xe8 [110121.667423][ C7] kernfs_drain+0xb0/0x114 [110121.667431][ C7] __kernfs_remove+0x16c/0x20c [110121.667436][ C7] kernfs_remove_by_name_ns+0x74/0xe8 [110121.667442][ C7] sysfs_remove_group+0x84/0xe8 [110121.667450][ C7] sysfs_remove_groups+0x34/0x58 [110121.667458][ C7] device_remove_groups+0x10/0x20 [110121.667464][ C7] device_release_driver_internal+0x164/0x2e4 [110121.667475][ C7] device_release_driver+0x18/0x28 [110121.667484][ C7] bus_remove_device+0xec/0x118 [110121.667491][ C7] device_del+0x1e8/0x4ac [110121.667498][ C7] device_unregister+0x18/0x38 [110121.667504][ C7] typec_unregister_altmode+0x30/0x44 [110121.667515][ C7] tcpm_reset_port+0xac/0x370 [110121.667523][ C7] tcpm_snk_detach+0x84/0xb8 [110121.667529][ C7] run_state_machine+0x4c0/0x1b68 [110121.667536][ C7] tcpm_state_machine_work+0x94/0xe4 [110121.667544][ C7] kthread_worker_fn+0x10c/0x244 [110121.667552][ C7] kthread+0x104/0x1d4 [110121.667557][ C7] ret_from_fork+0x10/0x20 [110121.667689][ C7] Workqueue: events dp_altmode_work [110121.667697][ C7] Call trace: [110121.667701][ C7] __switch_to+0x174/0x338 [110121.667710][ C7] __schedule+0x608/0x9f0 [110121.667717][ C7] schedule+0x7c/0xe8 [110121.667725][ C7] schedule_preempt_disabled+0x24/0x40 [110121.667733][ C7] __mutex_lock+0x408/0xdac [110121.667741][ C7] __mutex_lock_slowpath+0x14/0x24 [110121.667748][ C7] mutex_lock+0x40/0xec [110121.667757][ C7] tcpm_altmode_enter+0x78/0xb4 [110121.667764][ C7] typec_altmode_enter+0xdc/0x10c [110121.667769][ C7] dp_altmode_work+0x68/0x164 [110121.667775][ C7] process_one_work+0x1e4/0x43c [110121.667783][ C7] worker_thread+0x25c/0x430 [110121.667789][ C7] kthread+0x104/0x1d4 [110121.667794][ C7] ret_from_fork+0x10/0x20 Change tcpm_queue_vdm_unlocked to queue for tcpm_queue_vdm_work, que puede realizar la verificación de estado mientras mantiene el bloqueo TCPM mientras el bloqueo del modo Alt ya no está activo. Esto requiere una nueva estructura para almacenar los datos de VDM: altmode_vdm_event.

Se encontró una falla en GnuTLS. Existe una vulnerabilidad de doble liberación debido a una gestión incorrecta de la propiedad en la lógica de exportación de las entradas de Nombre Alternativo del Sujeto (SAN) que contienen un otro nombre. Si el OID de tipo no es válido o está mal formado, GnuTLS llamará a asn1_delete_structure() en un nodo ASN.1 que no le pertenece, lo que genera una condición de doble liberación cuando la función principal o el invocador intenta posteriormente liberar la misma estructura. Esta vulnerabilidad puede activarse utilizando únicamente las API públicas de GnuTLS y puede provocar denegación de servicio o corrupción de memoria, según el comportamiento del asignador.