Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrección de las sumas de comprobación establecidas en idpf_rx_rsc(). idpf_rx_rsc() utiliza skb_transport_offset(skb) cuando el encabezado de transporte aún no está establecido. Esto genera la siguiente advertencia para las compilaciones CONFIG_DEBUG_NET=y. DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)) [ 69.261620] ADVERTENCIA: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth [ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697 [ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748) [ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261687] ? report_bug (lib/bug.c:?) [ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285) [ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309) [ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf [ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf [ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf [ 69.261712] __napi_poll (net/core/dev.c:7194) [ 69.261716] net_rx_action (net/core/dev.c:7265) [ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293) [ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288) [ 69.261726] handle_softirqs (kernel/softirq.c:561)

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: 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: 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: 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: 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: 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: 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: sched/core: Evitar la reprogramación cuando las interrupciones están deshabilitadas David informó una advertencia observada durante la prueba del bucle kexec jump: Interrupciones habilitadas después de irqrouter_resume+0x0/0x50 ADVERTENCIA: CPU: 0 PID: 560 en drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 El seguimiento del indicador de interrupción correspondiente: hardirqs se habilitó por última vez en (15573): [] __up_console_sem+0x7e/0x90 hardirqs se desactivó por última vez en (15580): [] __up_console_sem+0x63/0x90. Esto significa que __up_console_sem() se invocó con las interrupciones habilitadas. Una instrumentación más detallada reveló que, en la sección de interrupción deshabilitada de kexec jump, una de las devoluciones de llamada syscore_suspend() despertó una tarea, lo que activó el indicador NEED_RESCHED. Una devolución de llamada posterior en la ruta de reanudación invocó cond_resched(), que a su vez condujo a la invocación del programador: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 Este es un problema de larga data, que probablemente se hizo más visible con los cambios recientes de printk. Algo hace una activación de tarea y el programador establece el indicador NEED_RESCHED. cond_resched() lo ve establecido e invoca schedule() desde un contexto completamente falso. El programador habilita interrupciones después del cambio de contexto, lo que causa la advertencia anterior al final. Algunas de las rutas de código en syscore_suspend()/resume() pueden provocar la activación de una activación con exactamente las mismas consecuencias. Puede que no lo hayan hecho todavía, pero como comparten mucho código con las operaciones normales, es solo cuestión de tiempo. El problema solo afecta a los modelos de programación PREEMPT_NONE y PREEMPT_VOLUNTARY. La preempción completa no se ve afectada, ya que cond_resched() está deshabilitado y la comprobación de preempción preemptible() tiene en cuenta la bandera de interrupción deshabilitada. Solucione el problema añadiendo una comprobación correspondiente a cond_resched().

IBM UrbanCode Deploy (UCD) 7.0 a 7.0.5.25, 7.1 a 7.1.2.21, 7.2 a 7.2.3.14 y 7.3 a 7.3.2.0 / IBM DevOps Deploy 8.0 a 8.0.1.4 y 8.1 a 8.1 podrían permitir el acceso no autorizado a otros servicios o la posible exposición de datos confidenciales debido a la falta de autenticación en su servicio Agent Relay.

IBM UrbanCode Deploy (UCD) versiones 7.1.2.21, 7.2 a 7.2.3.14 y 7.3 a 7.3.2.0 / IBM DevOps Deploy versiones 8.0 a 8.0.1.4 y 8.1 a 8.1 almacenan información de token de autenticación potencialmente confidencial en archivos de registro que un usuario local podría leer.