CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26940 – drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed
https://notcve.org/view.php?id=CVE-2024-26940
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the corresponding ttm_resource_manager is not allocated. This leads to a crash when trying to read from this file. Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file only when the corresponding ttm_resource_manager is allocated. crash> bt PID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep" #0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a #2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1 #4 [ffffb954506b3c70] no_context at ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887 #7 [ffffb954506b3d40] page_fault at ffffffffb360116e [exception RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003 RBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: cree la entrada debugfs ttm_resource_manager solo si es necesario. El controlador crea /sys/kernel/debug/dri/0/mob_ttm incluso cuando el ttm_resource_manager correspondiente no está asignado. Esto provoca un bloqueo al intentar leer este archivo. Agregue una marca para crear archivos de depuración mob_ttm, system_mob_ttm y gmr_ttm solo cuando se asigne el ttm_resource_manager correspondiente. crash> bt PID: 3133409 TAREA: ffff8fe4834a5000 CPU: 3 COMANDO: "grep" #0 [ffffb954506b3b20] machine_kexec en ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec en ffffffffb2bb598a #2 ffb954506b3c38] crash_kexec en ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end en ffffffffb2a2a9b1 # 4 [ffffb954506b3c70] no_context en ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore en ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault en ffffffffb2a7f887 #7 54506b3d40] page_fault en ffffffffb360116e [excepción RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb9545 06b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffff CS: 0010 SS : 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show en ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read en ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 00000000000000 03 PBR: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b A flaw was found in the vmwgfx module in the Linux kernel. Trying to read the /sys/kernel/debug/dri/0/mob_ttm file when the ttm_resource_manager is not allocated will cause a crash, resulting in a denial of service. • https://git.kernel.org/stable/c/af4a25bbe5e7e60ff696ef5c1ec48ab2d51c17c6 https://git.kernel.org/stable/c/016119154981d81c9e8f2ea3f56b9e2b4ea14500 https://git.kernel.org/stable/c/042ef0afc40fa1a22b3608f22915b91ce39d128f https://git.kernel.org/stable/c/25e3ce59c1200f1f0563e39de151f34962ab0fe1 https://git.kernel.org/stable/c/eb08db0fc5354fa17b7ed66dab3c503332423451 https://git.kernel.org/stable/c/4be9075fec0a639384ed19975634b662bfab938f https://access.redhat.com/security/cve/CVE-2024-26940 https://bugzilla.redhat.com/show_bug.cgi?id=2278218 • CWE-20: Improper Input Validation •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26939 – drm/i915/vma: Fix UAF on destroy against retire race
https://notcve.org/view.php?id=CVE-2024-26939
In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129] __gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation"). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async variant of wakeref put. • https://git.kernel.org/stable/c/d93939730347360db0afe6a4367451b6f84ab7b1 https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190 https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5 https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e https://access.redhat.com/security/cve/CVE-2024-26939 https://bugzilla.redhat.com/show_bug.cgi?id=2278220 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26938 – drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode()
https://notcve.org/view.php?id=CVE-2024-26938
In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() If we have no VBT, or the VBT didn't declare the encoder in question, we won't have the 'devdata' for the encoder. Instead of oopsing just bail early. We won't be able to tell whether the port is DP++ or not, but so be it. (cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733) En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() Si no tenemos VBT, o el VBT no declaró el codificador en cuestión, no tendremos los 'devdata' para el codificador. En lugar de huir, simplemente sal de la cárcel antes de tiempo. No podremos saber si el puerto es DP++ o no, pero que así sea. (cereza escogida del compromiso 26410896206342c8a80d2b027923e9ee7d33b733) • https://git.kernel.org/stable/c/72e4d3fb72e9f0f016946158a7d95304832768e6 https://git.kernel.org/stable/c/a891add409e3bc381f4f68c2ce9d953f1865cb1f https://git.kernel.org/stable/c/f4bbac954d8f9ab214ea1d4f385de4fa6bd92dd0 https://git.kernel.org/stable/c/94cf2fb6feccd625e5b4e23e1b70f39a206f82ac https://git.kernel.org/stable/c/32e39bab59934bfd3f37097d4dd85ac5eb0fd549 https://access.redhat.com/security/cve/CVE-2024-26938 https://bugzilla.redhat.com/show_bug.cgi?id=2278229 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26937 – drm/i915/gt: Reset queue_priority_hint on parking
https://notcve.org/view.php?id=CVE-2024-26937
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Reset queue_priority_hint on parking Originally, with strict in order execution, we could complete execution only when the queue was empty. Preempt-to-busy allows replacement of an active request that may complete before the preemption is processed by HW. If that happens, the request is retired from the queue, but the queue_priority_hint remains set, preventing direct submission until after the next CS interrupt is processed. This preempt-to-busy race can be triggered by the heartbeat, which will also act as the power-management barrier and upon completion allow us to idle the HW. We may process the completion of the heartbeat, and begin parking the engine before the CS event that restores the queue_priority_hint, causing us to fail the assertion that it is MIN. <3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1)) <0>[ 166.210781] Dumping ftrace buffer: <0>[ 166.210795] --------------------------------- ... <0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 } <0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646 <0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0 <0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659 <0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40 <0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 } <0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2 <0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin <0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2 <0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin <0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660 <0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns } <0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked <0>[ 167.303534] <idle>-0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040 <0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns } <0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns } <0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint ! • https://git.kernel.org/stable/c/22b7a426bbe1ebe1520f92da4cd1617d1e1b5fc4 https://git.kernel.org/stable/c/67944e6db656bf1e986aa2a359f866f851091f8a https://git.kernel.org/stable/c/fe34587acc995e7b1d7a5d3444a0736721ec32b3 https://git.kernel.org/stable/c/ac9b6b3e8d1237136c8ebf0fa1ce037dd7e2948f https://git.kernel.org/stable/c/7eab7b021835ae422c38b968d5cc60e99408fb62 https://git.kernel.org/stable/c/3b031e4fcb2740988143c303f81f69f18ce86325 https://git.kernel.org/stable/c/aed034866a08bb7e6e34d50a5629a4d23fe83703 https://git.kernel.org/stable/c/8fd9b0ce8c26533fe4d5d15ea15bbf7b9 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26935 – scsi: core: Fix unremoved procfs host directory regression
https://notcve.org/view.php?id=CVE-2024-26935
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix unremoved procfs host directory regression Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. • https://git.kernel.org/stable/c/88c3d3bb6469cea929ac68fd326bdcbefcdfdd83 https://git.kernel.org/stable/c/68c665bb185037e7eb66fb792c61da9d7151e99c https://git.kernel.org/stable/c/2a764d55e938743efa7c2cba7305633bcf227f09 https://git.kernel.org/stable/c/7e0ae8667fcdd99d1756922e1140cac75f5fa279 https://git.kernel.org/stable/c/be03df3d4bfe7e8866d4aa43d62e648ffe884f5f https://git.kernel.org/stable/c/73f030d4ef6d1ad17f824a0a2eb637ef7a9c7d51 https://git.kernel.org/stable/c/0053f15d50d50c9312d8ab9c11e2e405812dfcac https://git.kernel.org/stable/c/5c2386ba80e779a92ec3bb64ccadbedd8 •