Page 367 of 3000 results (0.010 seconds)

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: mm: turn folio_test_hugetlb into a PageType The current folio_test_hugetlb() can be fooled by a concurrent folio split into returning true for a folio which has never belonged to hugetlbfs. This can't happen if the caller holds a refcount on it, but we have a few places (memory-failure, compaction, procfs) which do not and should not take a speculative reference. Since hugetlb pages do not use individual page mapcounts (they are always fully mapped and use the entire_mapcount field to record the number of mappings), the PageType field is available now that page_mapcount() ignores the value in this field. In compaction and with CONFIG_DEBUG_VM enabled, the current implementation can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks in the PageHuge() testing path. [willy@infradead.org: update vmcoreinfo] Link: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org 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. • https://git.kernel.org/stable/c/9c5ccf2db04b8d7c3df363fdd4856c2b79ab2c6a https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32 https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: phy: marvell: a3700-comphy: Fix out of bounds read There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE. 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. • https://git.kernel.org/stable/c/934337080c6c59b75db76b180b509f218640ad48 https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813 https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07 https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d https://git.kernel.org/stable/c/e4308bc22b9d46cf33165c9dfaeebcf29cd56f04 • CWE-125: Out-of-bounds Read •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue drain_workqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queue_work() while drain_workqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: <TASK> ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? report_bug+0x1f8/0x200 ? • https://git.kernel.org/stable/c/c40bd7d9737bdcfb02d42765bc6c59b338151123 https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098 https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44 https://access.redhat.com/security/cve/CVE-2024-35991 https://bugzilla.redhat.com/show_bug.cgi?id=2281843 •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: dma: xilinx_dpdma: Fix locking There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like [ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: 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: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 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.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 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] drm_atomic_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] do_take_over_console+0x24c/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 [ 31.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] really_probe+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/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dma: xilinx_dpdma: bloqueo de reparación Hay varios lugares donde chan-&gt;lock o chan-&gt;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--- • https://git.kernel.org/stable/c/7cbb0c63de3fc218fd06ecfedb477772a4d12f76 https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076 https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11 https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557 https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-667: Improper Locking •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix oops during rmmod on single-CPU platforms During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: <TASK> __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 perf_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/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 <TASK> Fix the issue by preventing the migration of the perf context to an invalid target. 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. • https://git.kernel.org/stable/c/81dd4d4d6178306ab31db91bdc7353d485bdafce https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be https://access.redhat.com/security/cve/CVE-2024-35989 https://bugzilla.redhat.com/show_bug.cgi?id=2281847 •