Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ax25: soluciona el problema de recuento de netdev. El dev_tracker se agrega a ax25_cb en ax25_bind(). Cuando el dispositivo ax25 se está desconectando, el dev_tracker de ax25_cb debe desasignarse en ax25_kill_by_device() en lugar del dev_tracker de ax25_dev. El registro informado por ref_tracker se muestra a continuación: [80.884935] ref_tracker: referencia ya publicada. [80.885150] ref_tracker: asignado en: [80.885349] ax25_dev_device_up+0x105/0x540 [80.885730] ax25_device_event+0xa4/0x420 [80.885730] notifier_call_chain+0xc9/0x1e0 [80. 885730] __dev_notify_flags+0x138/0x280 [ 80.885730] dev_change_flags+0xd7/0x180 [ 80.885730 ] dev_ifsioc+0x6a9/0xa30 [ 80.885730] dev_ioctl+0x4d8/0xd90 [ 80.885730] sock_do_ioctl+0x1c2/0x2d0 [ 80.885730] sock_ioctl+0x38b/0x4f0 [ 80.885730] __se_sys_ioctl+0xad/0xf0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] Entry_SYSCALL_64_after_hwframe +0x67/0x6f [ 80.885730] ref_tracker: liberado en: [ 80.885730] ax25_device_event+0x272/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] 370 [80.885730] unregister_netdevice_many_notify+0x3b5/0x1180 [80.885730] unregister_netdev+0xcf /0x120 [ 80.885730] sixpack_close+0x11f/0x1b0 [ 80.885730] tty_ldisc_kill+0xcb/0x190 [ 80.885730] tty_ldisc_hangup+0x338/0x3d0 [ 80.885730] x740 [ 80.885730] tty_release+0x46e/0xd80 [ 80.885730] __fput+0x37f/0x770 [80.885730] __x64_sys_close+0x7b/0xb0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] Entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.893739] ------------[ cortar aquí ]--- ---- ----- [80.894030] ADVERTENCIA: CPU: 2 PID: 140 en lib/ref_tracker.c: 255 ref_tracker_free+0x47b/0x6b0 [80.894297] Módulos vinculados en: [80.894929] CPU: 2 pid: 140 Comm: ax25_conn_rel 6 no Tainted 6.9.0-rc4-g8cd26fd90c1a #11 [80.895190] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4 [80.895514] RIP:ref_tracker_free +0x47b /0x6b0 [ 80.895808] Código: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9 [ 80.896171] 0018:ffff888009edf8c0 EFLAGS: 00000286 [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000 [ 80.896502] RDX: 00000000000000001 RSI: 0000000000000246 RDI: ff88800a0d6518 [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a [ 80.897212] R10: dffffc0000000000 R11: 1b R12: ffff88800a4a31d4 [ 80.897859 ] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518 [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) 000000000000000 [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 80.900181] CR2: 00007fd88c001d48 CR3 : 000000000993e000 CR4: 00000000000006f0 ... [ 80.935774] ref_tracker: sp%d@000000000bb9df3d tiene 1/1 usuarios en [ 80.935774] ax25_bind+0x424/0x4e0 [ 80.93577 4] __sys_bind+0x1d9/0x270 [ 80.935774] __x64_sys_bind+0x75/0x80 [ 80.935774 ] do_syscall_64+0xc4/0x1b0 [ 80.935774] Entry_SYSCALL_64_after_hwframe+0x67/0x6f Cambie ax25_dev->dev_tracker al dev_tracker de ax25_cb para mitigar el error.

Una vulnerabilidad fue encontrada en PHPGurukul Directory Management System 1.0 y clasificada como problemática. Una función desconocida del archivo /admin/admin-profile.php del componente Searchbar es afectada por esta vulnerabilidad. La manipulación conduce a cross site scripting. El ataque se puede lanzar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-265213.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: Advertencia de corrección durante el rehash Como se explicó anteriormente, el trabajo retrasado del rehash migra filtros de una región a otra. Esto se hace iterando sobre todos los fragmentos (todos los filtros con la misma prioridad) en la región y en cada fragmento iterando sobre todos los filtros. Cuando el trabajo se queda sin créditos, almacena el fragmento y la entrada actuales como marcadores en el contexto por trabajo para saber dónde reanudar la migración la próxima vez que se programe el trabajo. En caso de error, el marcador de fragmento se restablece a NULL, pero sin restablecer los marcadores de entrada a pesar de ser relativos a él. Esto puede provocar que la migración se reanude desde una entrada que no pertenece al fragmento que se está migrando. A su vez, esto eventualmente conducirá a que se repita un fragmento como si fuera una entrada. Debido a cómo se definen las dos estructuras, esto no genera símbolos KASAN, sino advertencias como [1]. Para solucionarlo, cree un asistente que restablezca todos los marcadores y llámelo desde todos los lugares donde actualmente solo restablece el marcador de fragmentos. Por si acaso, llámelo también al iniciar un rehash completamente nuevo. Agregue una advertencia para evitar casos futuros. [1] ADVERTENCIA: CPU: 7 PID: 1076 en drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Módulos vinculados en: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted : GW 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP 0010:mlxsw_af k_encode+0x242/0x2f0 [... ] Seguimiento de llamadas: mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6 c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige el uso incorrecto de la API de lista. Tanto la función que migra todos los fragmentos dentro de una región como la función que migra todas las entradas dentro de un fragmento llaman a list_first_entry() en el respectivo listas sin verificar que las listas no estén vacías. Este es un uso incorrecto de la API, lo que genera la siguiente advertencia [1]. Para solucionarlo, regrese si las listas están vacías, ya que en este caso no hay nada que migrar. [1] ADVERTENCIA: CPU: 0 PID: 6437 en drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Módulos vinculados en: CPU: 0 PID: 6437 Comm: kworker/0:37 No contaminado 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP 0010:mlxsw_sp _acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [... ] Seguimiento de llamadas: mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 Process_one_work+0x151/0x370 Workers_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x3 0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: honrar el indicador inactivo de la tabla desde la ruta del evento de lanzamiento de netdev. Verifique el indicador inactivo de la tabla; de lo contrario, la ruta del evento de lanzamiento de netdev intenta cancelar el registro de un enlace que ya no está registrado. [524854.857999] ------------[ cortar aquí ]------------ [524854.858010] ADVERTENCIA: CPU: 0 PID: 3386599 en net/netfilter/core.c :501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 No contaminado 6.9.0-rc3+ #365 [524854.858869] Cola de trabajo: netns cleanup_net [524854 .858886] QEPD: 0010 :__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Código: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 83 y sigs 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 24854.858926] RAX: 00000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 00000000000000 01 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 00000000000000005 [524854.858962] R13: 16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971 ] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Seguimiento de llamadas: [ 524854.859006] [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: no utilice el indicador WQ_MEM_RECLAIM para la cola de trabajo Problema informado por el cliente durante las pruebas SRIOV, seguimiento de llamadas: cuando se cargan tanto el i40e como el controlador i40iw, se activa una advertencia en check_flush_dependency. Esto parece deberse a que la cola de trabajo del controlador i40e está asignada con el indicador WQ_MEM_RECLAIM, y la del i40iw no. También se encontró un error similar en el ice y se solucionó quitando la bandera. Haz lo mismo con el i40e también. [9 de febrero 09:08] ------------[ cortar aquí ]------------ [ +0.000004] cola de trabajo: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] está vaciando !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] ADVERTENCIA: CPU: 0 PID: 937 en kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Módulos vinculados en: snd_seq_dummy snd_hrtimer snd_seq snd_timer s nd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fusible [+0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: cargado No contaminado 6.8.0 -rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Nombre del hardware: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 15/12/2020 [ +0.0000 01] Cola de trabajo: i40e i40e_service_task [i40e ] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Código: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 RETRASOS: 00010282 [ + 0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [+0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 00000000000000000(0000) GS:ffff94d47f600000(000) 0) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ + 0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [+0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Seguimiento de llamadas : [ +0.000001] [ +0.000002] ? __advertir+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [+0.000002]? report_bug+0x195/0x1a0 [+0.000005]? handle_bug+0x3c/0x70 [+0.000003]? exc_invalid_op+0x14/0x70 [+0.000002]? asm_exc_invalid_op+0x16/0x20 [+0.000006]? check_flush_dependency+0x10b/0x120 [+0.000002]? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000 024] process_one_work+0x174/0x340 [+0.000003] worker_th ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: se corrigió la carga de kernels NOMMU de 64 bits después del inicio de la confirmación de RAM. 3335068f8721 ("riscv: use páginas PUD/P4D/PGD para el mapeo lineal") se agregó lógica para permitir el uso RAM debajo de la dirección de carga del kernel. Sin embargo, esto no funciona para NOMMU, donde PAGE_OFFSET está fijado a la dirección de carga del kernel. Dado que ese rango de memoria corresponde a los PFN por debajo de ARCH_PFN_OFFSET, la inicialización de mm se ejecuta desde el principio de mem_map y corrompe la memoria del kernel adyacente. Solucione este problema restaurando el comportamiento anterior de los núcleos NOMMU.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: idxd: soluciona errores durante rmmod en plataformas de CPU única Durante la eliminación del controlador idxd, se invoca la devolución de llamada sin conexión registrada como parte del proceso de limpieza. Sin embargo, en sistemas con una sola CPU en línea, no hay ningún destino válido disponible para migrar el contexto de rendimiento, lo que genera un error del kernel: ERROR: no se puede manejar el error de página para la dirección: 000000000002a2b8 #PF: acceso de escritura del supervisor en modo kernel #PF: error_code(0x0002) - página no presente PGD 1470e1067 P4D 0 Ups: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 No contaminado 6.8.0-rc6-dsa+ #57 Nombre de hardware: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 18/07/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Seguimiento de llamadas: __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault++0x65 /0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 f_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0 x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Solucione el problema impidiendo la migración del contexto de rendimiento a un destino no válido.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dma: xilinx_dpdma: bloqueo de reparación Hay varios lugares donde chan->lock o chan->vchan.lock no se mantuvieron. Agregue el bloqueo apropiado. Esto corrige advertencias de bloqueo como [31.077578] ------------[ cortar aquí ]------------ [ 31.077831] ADVERTENCIA: CPU: 2 PID: 40 en los controladores/ dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Módulos vinculados en: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 No contaminado 6.6.20+ #98 [ 31.07 8102] Nombre del hardware : xlnx,zynqmp (DT) [31.078169] Cola de trabajo: events_unbound deferred_probe_work_func [31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [31.078377] pc: xilinx_dpdma_chan_queue _transfer+0x274/0x5e0 [ 31.078473 ] lr: xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [31.078550] sp: ffffffc083bb2e10 [31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: 65a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 00000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9: 0001ffc082aa3def [31.079824 ] x8: 0001ffc082aa3dec x7: 0000000000000000 x6: 0000000000000516 [31.079982] x5: ffffffc7f8d43000 x4: ffffff88003c9c40 x3: ffffffffffffffff [ 31.0 80147] x2: ffffffc7f8d43000 x1: 00000000000000c0 x0: 0000000000000000 [31.080307] Rastreo de llamadas: [31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [31. 080518 ] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit +0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50 /0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered +0x2d0/0x34c [ 31.082663] Register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 3 1.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0 /0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] +0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207 device_initial_probe+0x14/0 x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451 ] Process_one_work+0x3ac/0x988 [31.084643] work_thread+0x398/0x694 [31.084752] kthread+0x1bc/0x1c0 [31.084848] ret_from_fork+0x10/0x20 [31.084932] sello de evento irq: 9 [31.084970] hardirqs habilitado por última vez en (64548): [ ] _raw_spin_unlock_irqrestore+0x80/0x90 [31.085157] ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: idxd: convertir spinlock a mutex para bloquear evl workqueue. Drain_workqueue() no se puede llamar de forma segura en un contexto de spinlock debido a una posible reprogramación de tareas. En el escenario de tareas múltiples, llamar a queue_work() mientras Drain_workqueue() generará un seguimiento de llamadas, ya que no se permite enviar un trabajo a una cola de trabajo agotadora en un contexto de bloqueo por giro. Seguimiento de llamadas: ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440? report_bug+0x1f8/0x200? handle_bug+0x3c/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? __queue_work+0x2b2/0x440 queue_work_on+0x28/0x30 idxd_misc_thread+0x303/0x5a0 [idxd] ? __schedule+0x369/0xb40? __pfx_irq_thread_fn+0x10/0x10 ? irq_thread+0xbc/0x1b0 irq_thread_fn+0x21/0x70 irq_thread+0x102/0x1b0 ? preempt_count_add+0x74/0xa0? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0x103/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 La implementación actual utiliza un bloqueo giratorio para proteger la cola de trabajo del registro de eventos y conducirá al seguimiento de llamadas debido a una posible reprogramación de tareas. Para solucionar el problema de bloqueo, convierta el spinlock a mutex, lo que permite llamar a Drain_workqueue() en un contexto seguro con bloqueo mutex. Este cambio garantiza una sincronización adecuada al acceder a la cola de trabajo del registro de eventos, lo que evita un posible seguimiento de llamadas y mejora la solidez general del código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: marvell: a3700-comphy: corrección de lectura fuera de los límites. Hay un acceso de lectura fuera de los límites de 'gbe_phy_init_fix[fix_idx].addr' en cada iteración después de que 'fix_idx' alcance ' ARRAY_SIZE(gbe_phy_init_fix)'. Asegúrese de que se utilice 'gbe_phy_init[addr]' cuando se manejen todos los elementos de la matriz 'gbe_phy_init_fix'. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: convierte folio_test_hugetlb en un PageType. El folio_test_hugetlb() actual puede ser engañado por una división de folio concurrente y devuelve verdadero para un folio que nunca ha pertenecido a hugetlbfs. Esto no puede suceder si la persona que llama tiene un recuento sobre él, pero tenemos algunos lugares (fallo de memoria, compactación, procfs) que no toman ni deben tomar una referencia especulativa. Dado que las páginas de Hugetlb no usan recuentos de mapas de páginas individuales (siempre están completamente asignadas y usan el campo Whole_mapcount para registrar el número de asignaciones), el campo PageType está disponible ahora que page_mapcount() ignora el valor en este campo. En compactación y con CONFIG_DEBUG_VM habilitado, la implementación actual puede resultar en un error, según lo informado por Luis. Esto sucede desde que 9c5ccf2db04b ("mm: eliminar HUGETLB_PAGE_DTOR") agregó efectivamente algunas comprobaciones de VM_BUG_ON() en la ruta de prueba de PageHuge(). [willy@infradead.org: actualizar vmcoreinfo] Enlace: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org