Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la limpieza de QoS de vport en caso de error. Al fallar la habilitación de QoS de vport, el nodo de programación nunca se liberaba, lo que causaba una fuga. Agregue la liberación faltante y restablezca el puntero del nodo de programación de vport a NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uprobes: Rechazar la página cero compartida en uprobe_write_opcode() Activamos el siguiente fallo en las pruebas de syzkaller: ERROR: Estado de página incorrecto en el proceso syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 000000000000000 raw: 000000000000000 0000000000000000 00000000ffffffffe 0000000000000000 página volcada porque: PAGE_FLAGS_CHECK_AT_FREE indicador(es) establecido(s) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x32/0x50 bad_page+0x69/0xf0 free_unref_page_prepare+0x401/0x500 free_unref_page+0x6d/0x1b0 uprobe_write_opcode+0x460/0x8e0 install_breakpoint.part.0+0x51/0x80 register_for_each_vma+0x1d9/0x2b0 __uprobe_register+0x245/0x300 bpf_uprobe_multi_link_attach+0x29b/0x4f0 link_create+0x1e2/0x280 __sys_bpf+0x75f/0xac0 __x64_sys_bpf+0x1a/0x30 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1 The following syzkaller test case can be used to reproduce: r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORING_OFF_SQ_RING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIO_API(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIO_API(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROG_LOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPF_LINK_CREATE_XDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40) La causa es que cero El pfn se establece en el PTE sin aumentar el recuento RSS en mfill_atomic_pte_zeropage() y el recuento de referencias del folio cero no aumenta en consecuencia. Luego, se realiza la misma operación en el pfn en uprobe_write_opcode()->__replace_page() para disminuir incondicionalmente el recuento RSS y el recuento de referencias de old_folio. Por lo tanto, se introducen dos errores: 1. El recuento RSS es incorrecto; al finalizar el proceso, check_mm() informa el error "Bad RSS-count" (recuento RSS incorrecto). 2. El folio reservado (folio cero) se libera cuando folio->refcount es cero; entonces, free_pages_prepare->free_page_is_bad() informa el error "Bad page state" (estado de página incorrecto). Hay más, la siguiente advertencia también podría activarse teóricamente: __replace_page() -> ... -> folio_remove_rmap_pte() -> VM_WARN_ON_FOLIO(is_zero_folio(folio), folio) Teniendo en cuenta que el impacto de uprobe en el folio cero es un caso muy raro, simplemente rechace el folio antiguo cero inmediatamente después de get_user_page_vma_remote(). [ mingo: Se limpió el registro de cambios ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: Se corrige el UAF en ovl_dentry_update_reval moviendo dput() en ovl_link_up. El problema se debía a que dput(upper) se llamaba antes de ovl_dentry_update_reval(), mientras que se seguía accediendo a upper->d_flags en ovl_dentry_remote(). Se mueve dput(upper) después de su último uso para evitar el use-after-free. ERROR: KASAN: slab-use-after-free en ovl_dentry_remote fs/overlayfs/util.c:162 [en línea] ERROR: KASAN: slab-use-after-free en ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 ovl_dentry_remote fs/overlayfs/util.c:162 [en línea] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [en línea] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Corrección de uso sospechoso de RCU. El commit ("iommu/vt-d: Asignar interrupciones de fallo DMAR localmente") movió la llamada a enable_drhd_fault_handling() a una ruta de código que no mantiene ningún bloqueo al recorrer la lista drhd. Corríjala asegurándose de que el bloqueo dmar_global_lock se mantenga al recorrer la lista drhd. Sin esta corrección, se activa la siguiente advertencia: ============================= ADVERTENCIA: uso sospechoso de RCU 6.14.0-rc3 #55 No contaminado ----------------------------- drivers/iommu/intel/dmar.c:2046 ¡Lista de RCU recorrida en una sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 1, debug_locks = 1 2 bloqueos mantenidos por cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, en: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, en: cpuhp_thread_fun+0x87/0x2c0 seguimiento de pila: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 No contaminado 6.14.0-rc3 #55 Seguimiento de llamadas: dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Mantener el bloqueo en enable_drhd_fault_handling() activa un aviso de bloqueo sobre un posible interbloqueo entre dmar_global_lock y cpu_hotplug_lock. Esto se evita al no mantener dmar_global_lock al llamar a iommu_device_register(), que inicia el proceso de sondeo del dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-integrity: Evitar la división por cero en el estado de la tabla en modo en línea. En modo en línea, el diario no se utiliza y journal_sectors es cero. Calcular la marca de agua del diario requiere dividir por journal_sectors, lo cual solo debe hacerse si el diario está configurado. De lo contrario, una simple consulta de tabla (dmsetup table) puede causar un error OOPS. Este error no se presentó en algunos sistemas, quizás solo debido a la optimización del compilador. En mi equipo de pruebas de 32 bits, esto falla de forma fiable con el siguiente error: : Oops: divide error: 0000 [#1] PREEMPT SMP : CPU: 0 UID: 0 PID: 2450 Comm: dmsetup Not tainted 6.14.0-rc2+ #959 : EIP: dm_integrity_status+0x2f8/0xab0 [dm_integrity] ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: bsg: Se corrige el fallo cuando falla el comando arpmb. Si el dispositivo no es compatible con arpmb, se producirá un fallo debido a la copia de datos de usuario en bsg_transport_sg_io_fn(). Si ufs_bsg_exec_advanced_rpmb_req() devuelve un error, no se debe establecer el valor de respuesta de la tarea. Seguimiento de fallos de memoria: 3,1290,531166405,-;ufshcd 0000:00:12.5: Error en la operación ARPMB: código de error -22 4,1308,531166555,-; Seguimiento de llamadas: 4,1309,531166559,-; 4,1310,531166565,-; ? show_regs+0x6d/0x80 4,1311,531166575,-; ? die+0x37/0xa0 4,1312,531166583,-; ? do_trap+0xd4/0xf0 4,1313,531166593,-; ? do_error_trap+0x71/0xb0 4,1314,531166601,-; ? usercopy_abort+0x6c/0x80 4,1315,531166610,-; ? exc_invalid_op+0x52/0x80 4,1316,531166622,-; ? usercopy_abort+0x6c/0x80 4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20 4,1318,531166643,-; ? usercopy_abort+0x6c/0x80 4,1319,531166652,-; __check_heap_object+0xe3/0x120 4,1320,531166661,-; check_heap_object+0x185/0x1d0 4,1321,531166670,-; __check_object_size.part.0+0x72/0x150 4,1322,531166679,-; __check_object_size+0x23/0x30 4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/userptr: corrección de la gestión de EFAULT Actualmente tratamos EFAULT de hmm_range_fault() como un error no fatal cuando se llama desde xe_vm_userptr_pin() con la idea de que queremos evitar matar toda la máquina virtual y arrojar un error, bajo el supuesto de que el usuario solo hizo una desasignación o algo así, y no tiene intención de tocar esa memoria de la GPU. En este punto, ya hemos eliminado los PTE, por lo que cualquier acceso debería generar un fallo de página, y si el pin también falla allí, se volverá fatal. Sin embargo, parece que es posible que la vma userptr aún esté en la lista de revinculación en preempt_rebind_work_func(), si tuviéramos que volver a intentar el pin debido a que algo sucede en el llamador antes de realizar el paso de revinculación, pero mientras tanto necesitamos volver a validar el userptr y esta vez golpeando el EFAULT. Esto explica un informe interno de usuario sobre el resultado: [ 191.738349] ADVERTENCIA: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe] [ 191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe] [ 191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe] [ 191.738690] Call Trace: [ 191.738692] [ 191.738694] ? show_regs+0x69/0x80 [ 191.738698] ? __warn+0x93/0x1a0 [ 191.738703] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe] [ 191.738759] ? report_bug+0x18f/0x1a0 [ 191.738764] ? handle_bug+0x63/0xa0 [ 191.738767] ? exc_invalid_op+0x19/0x70 [ 191.738770] ? asm_exc_invalid_op+0x1b/0x20 [ 191.738777] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe] [ 191.738834] ? ret_from_fork_asm+0x1a/0x30 [ 191.738849] bind_op_prepare+0x105/0x7b0 [xe] [ 191.738906] ? dma_resv_reserve_fences+0x301/0x380 [ 191.738912] xe_pt_update_ops_prepare+0x28c/0x4b0 [xe] [ 191.738966] ? kmemleak_alloc+0x4b/0x80 [ 191.738973] ops_execute+0x188/0x9d0 [xe] [ 191.739036] xe_vm_rebind+0x4ce/0x5a0 [xe] [ 191.739098] ? trace_hardirqs_on+0x4d/0x60 [ 191.739112] preempt_rebind_work_func+0x76f/0xd00 [xe] Seguido de NPD, al ejecutar alguna carga de trabajo, ya que el grupo de secuencias nunca se rellenó, pero el administrador de máquinas virtuales (VMMA) sigue marcado para revincular cuando debería omitirse para este caso especial de EFAULT. Esto se ha confirmado para corregir el informe del usuario. v2 (MattB): - Se ha movido a una versión anterior. v3 (MattB): - Actualizar el mensaje de confirmación para dejar claro que esto realmente soluciona el problema. (seleccionado del commit 6b93cb98910c826c2e2004942f8b060311e43618)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el use-after-free en el inodo al escanear la raíz durante la reducción de em. En btrfs_scan_root(), accedemos a la raíz del inodo (y a fs_info) en una llamada a btrfs_fs_closing() después de haber programado el inodo para una entrada retrasada, lo que puede resultar en un use-after-free en el inodo en caso de que el kthread más limpio realice la entrada antes de que desreferenciamos el inodo en la llamada a btrfs_fs_closing(). Se soluciona esto usando la fs_info ya almacenada en una variable local en lugar de hacer inode->root->fs_info.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: siempre maneja la eliminación de dirección bajo el bloqueo del socket msk Syzkaller informó un splat lockdep en la ruta de control de PM: ADVERTENCIA: CPU: 0 PID: 6693 en ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [en línea] ADVERTENCIA: CPU: 0 PID: 6693 en ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [en línea] ADVERTENCIA: CPU: 0 PID: 6693 en ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Módulos vinculado: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 No contaminado 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Nombre del hardware: Google Compute Engine/Google Compute Engine, BIOS Google 27/12/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [en línea] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [en línea] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Código: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 De hecho, el PM puede intentar enviar una RM_ADDR a través de un msk sin adquirir primero el bloqueo del socket msk. La ruta de código con errores proviene de una optimización anterior: cuando no hay subflujos, el PM no debería (normalmente) enviar notificaciones RM_ADDR. La afirmación anterior es incorrecta, ya que sin bloqueos, otro proceso podría concurrir ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: gl620a: corrección de la comprobación de endpoints en genelink_bind(). Syzbot informa [1] de una advertencia en usb_submit_urb() provocada por inconsistencias entre los endpoints esperados y los realmente presentes en el controlador gl620a. Dado que genelink_bind() no verifica correctamente si el dispositivo proporciona los eps especificados (en este caso, uno fabricado artificialmente), es posible que se produzca una discrepancia. Solucione el problema recurriendo a la función de utilidad usbnet, usbnet_get_endpoints(), normalmente reservada para este problema. Compruebe los endpoints y vuelva antes de continuar si falta alguno. [1] Informe de Syzbot: usb 5-1: Fabricante: syz usb 5-1: Número de serie: syz usb 5-1: ¿descriptor de configuración 0? gl620a 5-1:0.23 usb0: registro 'gl620a' en usb-dummy_hcd.0-1, ... ------------[ cortar aquí ]------------ usb 5-1: transferencia urb FALSA, tubería 3 != tipo 1 ADVERTENCIA: CPU: 2 PID: 1841 en drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Módulos vinculados: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 No contaminado 6.12.0-syzkaller-07834-g06afb0f36106 #0 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Rastreo de llamadas: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: npcm: deshabilitar el bit de habilitación de interrupción antes de devm_request_irq El cliente informa que hay un problema de bloqueo suave relacionado con el controlador i2c. Después de verificar, el módulo i2c estaba haciendo una transferencia tx y la máquina bmc se reinicia en medio de la transacción i2c, el módulo i2c mantiene el estado sin reiniciarse. Debido a dicho estado del módulo i2c, el controlador de irq i2c sigue activándose ya que el controlador de irq i2c se registra en el proceso de arranque del kernel después de que la máquina bmc esté haciendo un reinicio en caliente. El temporizador de vigilancia de bloqueo suave detiene la activación continua. Deshabilite el bit de habilitación de interrupción en el módulo i2c antes de llamar a devm_request_irq para corregir este problema, ya que el bit de estado relativo de i2c es de solo lectura. Aquí está el registro de bloqueo suave. [ 28.176395] watchdog: ERROR: bloqueo suave: ¡CPU n.° 0 bloqueada durante 26 s! [swapper/0:1] [ 28.183351] Módulos vinculados: [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.15.120-yocto-s-dirty-bbebc78 #1 [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 28.208128] pc : __do_softirq+0xb0/0x368 [ 28.212055] lr : __do_softirq+0x70/0x368 [ 28.215972] sp : ffffff8035ebca00 [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 [ 28.290611] Call trace: [ 28.293052] __do_softirq+0xb0/0x368 [ 28.296625] __irq_exit_rcu+0xe0/0x100 [ 28.300374] irq_exit+0x14/0x20 [ 28.303513] handle_domain_irq+0x68/0x90 [ 28.307440] gic_handle_irq+0x78/0xb0 [ 28.311098] call_on_irq_stack+0x20/0x38 [ 28.315019] do_interrupt_handler+0x54/0x5c [ 28.319199] el1_interrupt+0x2c/0x4c [ 28.322777] el1h_64_irq_handler+0x14/0x20 [ 28.326872] el1h_64_irq+0x74/0x78 [ 28.330269] __setup_irq+0x454/0x780 [ 28.333841] request_threaded_irq+0xd0/0x1b4 [ 28.338107] devm_request_threaded_irq+0x84/0x100 [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 [ 28.346990] platform_probe+0x6c/0xc4 [ 28.350653] really_probe+0xcc/0x45c [ 28.354227] __driver_probe_device+0x8c/0x160 [ 28.358578] driver_probe_device+0x44/0xe0 [ 28.362670] __driver_attach+0x124/0x1d0 [ 28.366589] bus_for_each_dev+0x7c/0xe0 [ 28.370426] driver_attach+0x28/0x30 [ 28.373997] bus_add_driver+0x124/0x240 [ 28.377830] driver_register+0x7c/0x124 [ 28.381662] __platform_driver_register+0x2c/0x34 [ 28.386362] npcm_i2c_init+0x3c/0x5c [ 28.389937] do_one_initcall+0x74/0x230 [ 28.393768] kernel_init_freeable+0x24c/0x2b4 [ 28.398126] kernel_init+0x28/0x130 [ 28.401614] ret_from_fork+0x10/0x20 [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks [ 28.411011] SMP: stopping secondary CPUs [ 28.414933] Kernel Offset: disabled [ 28.418412] CPU features: 0x00000000,00000802 [ 28.427644] Reiniciando en 20 segundos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/fbdev-dma: Se ha añadido un búfer de sombra para E/S diferida. Las áreas de DMA no están necesariamente respaldadas por struct page, por lo que no podemos confiar en él para la E/S diferida. Se asigna un búfer de sombra a los controladores que requieren E/S diferida y se utiliza como memoria de framebuffer. Se corrigen los errores del controlador "No se puede gestionar la desreferencia de puntero nulo del kernel en la dirección virtual" o "No se puede gestionar la solicitud de paginación del kernel en la dirección virtual". El parche divide drm_fbdev_dma_driver_fbdev_probe() en una asignación inicial, que crea el objeto de búfer respaldado por DMA, y una cola, que configura las estructuras de datos fbdev. Hay una función de cola para asignaciones directas de memoria y otra para E/S diferida con el búfer de sombra. Ya no es posible utilizar la E/S diferida sin el búfer de sombra. Se puede volver a agregar si existe una prueba confiable de una página de estructura utilizable en el objeto de búfer respaldado por DMA asignado.