Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí la última para este caso porque el único sitio de llamada en el árbol, drivers/net/phy/phy_device.c nunca se compila como modular. (CONFIG_PHYLIB es booleano)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: altera: Se corrige la pérdida de recuento de referencias en altera_tse_mdio_create Cada iteración de for_each_child_of_node() disminuye el recuento de referencias del nodo anterior. Cuando se interrumpe un bucle for_each_child_of_node(), debemos llamar explícitamente a of_node_put() en el nodo secundario cuando ya no lo necesitamos. Agregue of_node_put() faltante para evitar la pérdida de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: advertencia de corrección en ext4_handle_inode_extension Tenemos el siguiente problema: Error EXT4-fs (device loop0) en ext4_reserve_inode_write:5741: Sin memoria Error EXT4-fs (device loop0): ext4_setattr:5462: inodo n.º 13: comm syz-executor.0: error mark_inode_dirty Error EXT4-fs (device loop0) en ext4_setattr:5519: Sin memoria Error EXT4-fs (device loop0): ext4_ind_map_blocks:595: inodo n.º 13: comm syz-executor.0: No se pueden asignar bloques para inodos no asignados a extensión con bigalloc ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 4361 en fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Módulos vinculados: CPU: 1 PID: 4361 Comm: syz-executor.0 No contaminado 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 000000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 00000000000000a R13: 000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 El problema anterior puede ocurrir de la siguiente manera: Suponga que inode.i_size=4096 EXT4_I(inodo)->i_disksize=4096 paso 1: establezca inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inodo)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk devolver -->ENOMEM ... si (!error) ->no se actualizará i_size i_size_write(inodo, attr->ia_size); Ahora: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 paso 2: Escritura directa de 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->devuelve error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Entonces activa la advertencia. Para resolver el problema anterior, si la marca de inodo sucio falló en ext4_setattr simplemente configure 'EXT4_I(inode)->i_disksize' con el valor anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: E-Switch, emparejar solo dispositivos compatibles con OFFLOADS El emparejamiento con devcom solo es posible en dispositivos que admiten LAG. Filtrar en función de las capacidades de retraso. Esto soluciona un problema en el que se llamaba a mlx5_get_next_phys_dev() sin mantener el bloqueo de la interfaz. Este problema se encontró cuando el commit bc4c2f2e0179 ("net/mlx5: Lag, filtrar dispositivos no compatibles") agregó una afirmación que verifica que se mantenga el bloqueo de la interfaz. ADVERTENCIA: CPU: 9 PID: 1706 en drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Módulos vinculados en: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [última descarga: mlx5_core] CPU: 9 PID: 1706 Comm: devlink No contaminado 5.18.0-rc7+ #11 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Código: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffff88811b398000 RCX: 000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/huge_memory: Se soluciona la pérdida de memoria del nodo xarray Si xas_split_alloc() no puede asignar los nodos necesarios para completar la división de la entrada xarray, establece xa_state en -ENOMEM, que xas_nomem() interpreta como "Asigne más memoria", no como "Libere cualquier memoria innecesaria" (que era el resultado previsto). Es confuso usar xas_nomem() para liberar memoria en este contexto, así que llame a xas_destroy() en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu/cs: hace que los comandos con 0 fragmentos tengan un comportamiento ilegal. Enviar un comando con 0 fragmentos provoca un error más adelante, que se detecta al intentar ejecutar el controlador de espacio de usuario incorrecto. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000001d8 [172536.665188] #PF: acceso de lectura del supervisor en modo núcleo [172536.665189] #PF: error_code(0x0000) - página no presente [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: PO 5.10.81 #1-NixOS [172536.665199] Nombre del hardware: Para ser completado por el OEM Para ser completado por el OEM/CROSSHAIR V FORMULA-Z, BIOS 2201 23/03/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Código: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 00000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Seguimiento de llamadas: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Error: https://gitlab.freedesktop.org/drm/amd/-/issues/2018

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/etnaviv: comprobar mapeo cosechado en etnaviv_iommu_unmap_gem Cuando el mapeo ya fue cosechado, anular el mapeo debe ser una operación nula, ya que de lo contrario intentaríamos eliminar el mapeo dos veces, corrompiendo las estructuras de datos involucradas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: dlmfs: se corrige la gestión de errores de user_dlm_destroy_lock Cuando user_dlm_destroy_lock fallaba, no limpiaba las banderas que establecía antes de salir. Para USER_LOCK_IN_TEARDOWN, si esta función falla debido a que el bloqueo aún está en uso, la próxima vez que unlink invoque esta función, devolverá éxito y luego unlink eliminará el inodo y la dentry si el bloqueo no está en uso (archivo cerrado), pero el bloqueo dlm aún está vinculado en el recurso de bloqueo dlm, luego cuando bast ingrese, activará un pánico debido a use after free. Vea el siguiente seguimiento de llamada de pánico. Para solucionar esto, USER_LOCK_IN_TEARDOWN debe revertirse si falla. Y también debe devolverse un error si USER_LOCK_IN_TEARDOWN está configurado para informar al usuario que unlink falló. En el caso de que falle ocfs2_dlm_unlock, además de USER_LOCK_IN_TEARDOWN, también se requiere borrar USER_LOCK_BUSY. Aunque se libere el bloqueo de giro en el medio, pero USER_LOCK_IN_TEARDOWN aún esté configurado, para USER_LOCK_BUSY, si antes de cada lugar que espera en este indicador, se marca USER_LOCK_IN_TEARDOWN para que se libere, eso asegurará que ningún flujo espere en el indicador de ocupado establecido por user_dlm_destroy_lock(), entonces podemos simplemente revertir USER_LOCK_BUSY cuando falla ocfs2_dlm_unlock. Corrija user_dlm_cluster_lock(), que es la única función que no sigue esto. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: desvincular 004fb0000060000b5a90b8c847b72e1, error -16 de la destrucción [ 989.757536] ------------[ cortar aquí ]------------ [ 989.757709] ¡ERROR del kernel en fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] código de operación no válido: 0000 [#1] SMP [ 989.758027] Módulos vinculados en: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf puente stp llc rds_rdma enlace rds ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt soporte de proveedor de iTCO pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [última descarga: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Contaminado: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Nombre del hardware: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 17/06/2021 [ 989.762599] tarea: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[] [] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: CT: Se corrige la limpieza de CT antes de la limpieza de las reglas ct de TC La limpieza de CT supone que todas las reglas tc se eliminaron primero y, por lo tanto, es libre de eliminar los recursos compartidos de CT (por ejemplo, dr_action fwd_action que se comparte para todas las tuplas). Pero actualmente para el enlace ascendente, esto sucede a la inversa, lo que provoca el siguiente rastro. La limpieza de CT se llama desde: mlx5e_cleanup_rep_tx()->mlx5e_cleanup_uplink_rep_tx()-> mlx5e_rep_tc_cleanup()->mlx5e_tc_esw_cleanup()-> mlx5_tc_ct_clean() Solo después, se llama a la limpieza de tc desde: mlx5e_cleanup_rep_tx()->mlx5e_tc_ht_cleanup() que habría eliminado todas las reglas de tc ct y, por lo tanto, eliminaría todas las tuplas descargadas. Corrija esto invirtiendo el orden de init y on cleanup, lo que dará como resultado tc cleanup y luego ct cleanup. [ 9443.593347] ADVERTENCIA: CPU: 2 PID: 206774 en drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core] [ 9443.593349] Módulos vinculados en: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliar(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan enlace geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount nf_nat mst_pciconf(O) dm_multipath sbsa_gwdt uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio mlx_bootctl(O) bluefield_edac sch_fq_codel tablas ip ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 crct10dif_ce i2c_mlxbf gpio_mlxbf2 mlxbf_gige aes_neon_bs aes_neon_blk [última descarga: mlx5_ib] [ 9443.593419] CPU: 2 PID: 206774 Comm: modprobe Contaminado: GO 5.4.0-1023.24.gc14613d-bluefield #1 [ 9443.593422] Nombre del hardware: https://www.mellanox.com SoC BlueField/SoC BlueField, BIOS BlueField:143ebaf 11 de enero de 2022 [ 9443.593424] estado de la página: 20000005 (nzCv daif -PAN -UAO) [ 9443.593489] computadora personal: mlx5dr_action_destroy+0x188/0x1a0 [núcleo mlx5] [ 9443.593545] estado de la línea: mlx5_ct_fs_smfs_destroy+0x24/0x30 [núcleo mlx5] [ 9443.593546] servidor de correo: ffff8000135dbab0 [ 9443.593548] x29: ffff8000135dbab0 x28: ffff0003a6ab8e80 [ 9443.593550] x27: 0000000000000000 x26: ffff0003e07d7000 [ 9443.593552] x25: ffff800009609de0 x24: ffff000397fb2120 [ 9443.593554] x23: ffff0003975c0000 x22: 0000000000000000 [ 9443.593556] x21: ffff0003975f08c0 x20: ffff800009609de0 [ 9443.593558] x19: ffff0003c8a13380 x18: 0000000000000014 [ 9443.593560] x17: 0000000067f5f125 x16: 000000006529c620 [ 9443.593561] x15: 000000000000000b x14: 0000000000000000 [ 9443.593563] x13: 0000000000000002 x12: 0000000000000001 [ 9443.593565] x11: ffff800011108868 x10: 0000000000000000 [ 9443.593567] x9 : 0000000000000000 x8 : ffff8000117fb270 [ 9443.593569] x7 : ffff0003ebc01288 x6 : 0000000000000000 [ 9443.593571] x5 : ffff800009591ab8 x4 : fffffe000f6d9a20 [ 9443.593572] x3 : 0000000080040001 x2 : fffffe000f6d9a20 [ 9443.593574] x1 : ffff8000095901d8 x0 : 0000000000000025 [ 9443.593577] Rastreo de llamadas: [ 9443.593634] mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core] [ 9443.593688] mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core] [ 9443.593743] mlx5_tc_ct_clean+0x34/0xa8 [mlx5_core] [ 9443.593797] mlx5e_tc_esw_cleanup+0x58/0x88 [mlx5_core] [ 9443.593851] mlx5e_rep_tc_cleanup+0x24/0x30 [mlx5_core] [ 9443.593905] mlx5e_cleanup_rep_tx+0x6c/0x78 [mlx5_core] [ 9443.593959] mlx5e_detach_netdev+0x74/0x98 [mlx5_core] [ 9443.594013] mlx5e_netdev_change_profile+0x70/0x180 [mlx5_core] [ 9443.594067] mlx5e_netdev_attach_nic_profile+0x34/0x40 [mlx5_core] [ 9443.594122] mlx5e_vport_rep_unload+0x15c/0x1a8 [mlx5_co ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL y __init es una mala combinación porque la sección .init.text se libera después de la inicialización. Por lo tanto, los módulos no pueden usar símbolos anotados __init. El acceso a un símbolo liberado puede terminar con un pánico del kernel. modpost solía detectarlo, pero ha estado roto durante una década. Recientemente, arreglé modpost para que comenzara a advertirlo nuevamente, luego esto apareció en las compilaciones de linux-next. Hay dos formas de solucionarlo: - Eliminar __init - Eliminar EXPORT_SYMBOL Elegí esto último para este caso porque el llamador (net/ipv6/seg6.c) y el llamador (net/ipv6/seg6_hmac.c) pertenecen al mismo módulo. Parece una llamada de función interna en ipv6.ko.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ip_gre: prueba csum_start en lugar del encabezado de transporte GRE con TUNNEL_CSUM aplicará la descarga de suma de comprobación local en los paquetes CHECKSUM_PARTIAL. ipgre_xmit debe validar csum_start después de un skb_pull opcional, de lo contrario lco_csum puede provocar un desbordamiento. La comprobación original era if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; Esto tenía falsos positivos cuando skb_checksum_start no está definido: cuando ip_summed no es CHECKSUM_PARTIAL. Una mejora discutida fue sencilla if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; Pero finalmente se revisó más a fondo: - restringir la verificación a la única rama donde sea necesario, en una ruta GRE poco común que usa header_ops y llama a skb_pull. - probar skb_transport_header, que se establece junto con csum_start en skb_partial_csum_set en la ruta de datos header_ops normal. Resulta que skbs puede llegar a esta rama sin el encabezado de transporte establecido, por ejemplo, a través de la redirección BPF. Revise la verificación nuevamente para verificar csum_start directamente, y solo si CHECKSUM_PARTIAL. Deje la verificación en la ubicación actualizada. Verifique el campo independientemente de si TUNNEL_CSUM está configurado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, arm64: Borrar prog->jited_len junto con prog->jited syzbot informó un intento ilegal de copy_to_user() desde bpf_prog_get_info_by_fd() [1] Todavía no hubo reproducción de este error, pero creo que el commit 0aef499f3172 ("mm/usercopy: Detectar desbordamientos de vmalloc") está exponiendo un error anterior en bpf arm64. bpf_prog_get_info_by_fd() analiza prog->jited_len para determinar si la imagen JIT se puede copiar al espacio de usuario. Mi teoría es que syzbot logró obtener un programa donde prog->jited_len se ha establecido en 43, mientras que prog->bpf_func se ha borrado. No está claro por qué copy_to_user(uinsns, NULL, ulen) está activando esta advertencia en particular. Pensé que find_vma_area(NULL) no encontraría un vm_struct. Como no tenemos el bloqueo de giro vmap_area_lock, es posible que el vm_struct encontrado fuera basura. [1] usercopy: ¡Se detectó un intento de exposición de memoria del kernel desde vmalloc (desplazamiento 792633534417210172, tamaño 43)! ¡ERROR del kernel en mm/usercopy.c:101! Error interno: Oops - BUG: 0 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 25002 Comm: syz-executor.1 No contaminado 5.18.0-syzkaller-10139-g8291eaafed36 #0 Nombre del hardware: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 00000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9: 657275736f707865 x8: ffff80000a30c550 x7: ffff80000b773830 x6: ffff80000b773830 x5: 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 00000000000000064 Rastreo de llamadas: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [en línea] __check_object_size mm/usercopy.c:252 [en línea] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [en línea] check_copy_size include/linux/thread_info.h:235 [en línea] copia_al_usuario include/linux/uaccess.h:159 [en línea] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5019 [en línea] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invocar_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Código: aa0003e3 d00038c0 91248000 97fff65f (d4210000)