Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige la desinicialización de VF en la ruta de error. Si ice_ena_vfs() falla tras llamar a ice_create_vf_entries(), libera todas las VF sin eliminarlas de la lista de buzones PF-VF de la instantánea, lo que provoca la corrupción de la lista. Reproductor: devlink dev eswitch set $PF1_PCI mode switchdev ip ls $PF1 up ip ls $PF1 promisc on sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfs sleep 1 echo 1 > /sys/class/net/$PF1/device/sriov_numvfs Rastreo (minimizado): corrupción de list_add. siguiente->anterior debería ser anterior (ffff8882e241c6f0), pero era 0000000000000000. (siguiente=ffff888455da1330). ¡ERROR del núcleo en lib/list_debug.c:29! RIP: 0010:__list_add_valid_or_report+0xa6/0x100 ice_mbx_init_vf_info+0xa7/0x180 [ice] ice_initialize_vf_entry+0x1fa/0x250 [ice] ice_sriov_configure+0x8d7/0x1520 [ice] ? __percpu_ref_switch_mode+0x1b1/0x5d0 ? __pfx_ice_sriov_configure+0x10/0x10 [ice] A veces, un informe de KASAN se puede ver con un seguimiento de pila similar: ERROR: KASAN: use-after-free en __list_add_valid_or_report+0xf1/0x100. Los VF se añaden a esta lista en ice_mbx_init_vf_info(), pero solo se eliminan en ice_free_vfs(). Traslada la eliminación a ice_free_vf_entries(), que también se invoca en otros lugares donde se eliminan VF (incluido el propio ice_free_vfs()).

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: RDMA/bnxt_re: corrige los detalles de la página para el srq creado por los consumidores del kernel. Al usar el objetivo nvme con use_srq activado, se detecta el siguiente pánico del kernel. [ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg desactivado codificación: cláusula 91 RS(544,514) [ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI .. [ 566.393799] [ 566.393807] ? __die_body+0x1a/0x60 [ 566.393823] ? die+0x38/0x60 [ 566.393835] ? do_trap+0xe4/0x110 [ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [ 566.393881] ? do_error_trap+0x7c/0x120 [ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [ 566.393911] ? exc_divide_error+0x34/0x50 [ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [ 566.393939] ? asm_exc_divide_error+0x16/0x20 [ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re] [ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re] [ 566.394057] ? srso_return_thunk+0x5/0x5f [ 566.394068] ? __init_swait_queue_head+0x4a/0x60 [ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core] [ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma] [ 566.394174] ? lock_release+0x22c/0x3f0 [ 566.394187] ? srso_return_thunk+0x5/0x5f La información de tamaño y desplazamiento de página se configura solo para las SRQ de espacio de usuario. También se configura para las SRQ de espacio de kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Se ha corregido el bloqueo implícito de ODP al cancelar el registro del padre. Se ha corregido la función destroy_unused_implicit_child_mr() para evitar que se bloquee durante la cancelación del registro del padre, como se indica a continuación [1]. Al ejecutar destroy_unused_implicit_child_mr(), el contador de referencias del padre MR implícito se incrementa mediante refcount_inc_not_zero(). Se debe realizar la decrementación correspondiente si no se llama a free_implicit_child_mr_work(). El código se ha actualizado para gestionar correctamente el contador de referencias que se incrementó. [1] INFORMACIÓN: La tarea python3:2157 se bloqueó durante más de 120 segundos. No contaminada. 6.12.0-rc7+ #1633 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000 Call Trace: __schedule+0x420/0xd30 schedule+0x47/0x130 __mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib] ? __pfx_autoremove_wake_function+0x10/0x10 ib_dereg_mr_user+0x5f/0x120 [ib_core] ? lock_release+0xc6/0x280 destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs] uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs] uobj_destroy+0x3f/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs] ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs] ? lock_acquire+0xc1/0x2f0 ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs] ? lock_release+0xc6/0x280 ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70 ? kmem_cache_free+0x221/0x400 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f20f21f017b RSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017b RDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890 R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Se corrige un WARN durante dereg_mr para el tipo DM. Las regiones de memoria (MR) de tipo DM (memoria del dispositivo) no tienen un umem asociado. En el flujo __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs(), el código toma incorrectamente la rama equivocada al intentar llamar a dma_unmap_single() en una dirección DMA no asignada. Esto genera un WARN [1], como se muestra a continuación. El problema se resuelve considerando correctamente el tipo DM y asegurando que se seleccione la rama correcta en mlx5_free_priv_descs(). [1] ADVERTENCIA: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90 Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00 RSP: 0018:ffffc90001913a10 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x84/0x190 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0xf8/0x1c0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 dma_unmap_page_attrs+0xe6/0x290 mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib] __mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib] ? _raw_spin_unlock_irq+0x24/0x40 ? wait_for_completion+0xfe/0x130 ? rdma_restrack_put+0x63/0xe0 [ib_core] ib_dereg_mr_user+0x5f/0x120 [ib_core] ? lock_release+0xc6/0x280 destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs] uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs] uobj_destroy+0x3f/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs] ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs] ? lock_acquire+0xc1/0x2f0 ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs] ? lock_release+0xc6/0x280 ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f537adaf17b Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270 R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190 R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: Añadir protección de bloqueo de lectura de RCU a perf_iterate_ctx(). La función perf_iterate_ctx() recorre la lista de RCU, pero actualmente carece de protección de bloqueo de lectura de RCU. Esto genera advertencias de lockdep al ejecutar perf probe con unshare(1) en CONFIG_PROVE_RCU_LIST=y: ADVERTENCIA: uso sospechoso de RCU kernel/events/core.c:8168 ¡Lista de RCU recorrida en la sección de no lectura! Rastreo de llamadas: lockdep_rcu_suspicious ? perf_event_addr_filters_apply perf_iterate_ctx perf_event_exec begin_new_exec ? load_elf_phdrs load_elf_binary ? lock_acquire ? find_held_lock ? bprm_execve bprm_execve do_execveat_common.isra.0 __x64_sys_execve do_syscall_64 entry_SYSCALL_64_after_hwframe Esta protección ya existía, pero se eliminó en la confirmación bd2756811766 ("perf: Reescribir la gestión del contexto principal"). Se ha añadido de nuevo el par necesario rcu_read_lock()/rcu_read_unlock() en la llamada a perf_iterate_ctx() en perf_event_exec(). [mingo: Usar scoped_guard() como sugirió Peter]

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