CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26942 – net: phy: qcom: at803x: fix kernel panic with at8031_probe
https://notcve.org/view.php?id=CVE-2024-26942
In the Linux kernel, the following vulnerability has been resolved: net: phy: qcom: at803x: fix kernel panic with at8031_probe On reworking and splitting the at803x driver, in splitting function of at803x PHYs it was added a NULL dereference bug where priv is referenced before it's actually allocated and then is tried to write to for the is_1000basex and is_fiber variables in the case of at8031, writing on the wrong address. Fix this by correctly setting priv local variable only after at803x_probe is called and actually allocates priv in the phydev struct. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: qcom: at803x: corrige el pánico del kernel con at8031_probe Al reelaborar y dividir el controlador at803x, en la función de división de los PHY de at803x se agregó un error de desreferencia NULL donde se hace referencia a priv antes de que realmente se asigne y luego se intenta escribir para las variables is_1000basex e is_fiber en el caso de at8031, escribiendo en la dirección incorrecta. Solucione este problema configurando correctamente la variable local priv solo después de llamar a at803x_probe y realmente asignar priv en la estructura phydev. • https://git.kernel.org/stable/c/25d2ba94005fac18fe68878cddff59a67e115554 https://git.kernel.org/stable/c/a8a296ad9957b845b89bcf48be1cf8c74875ecc3 https://git.kernel.org/stable/c/6a4aee277740d04ac0fd54cfa17cc28261932ddc • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26941 – drm/dp: Fix divide-by-zero regression on DP MST unplug with nouveau
https://notcve.org/view.php?id=CVE-2024-26941
In the Linux kernel, the following vulnerability has been resolved: drm/dp: Fix divide-by-zero regression on DP MST unplug with nouveau Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP DisplayPort 1.2 MST hub (the same regression does not appear when using a Cable Matters DisplayPort 1.4 MST hub). Trace: divide error: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744 Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018 RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper] Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31 RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206 RAX: ffffffffffffffff RBX: 0000000000000000 RCX: 0000000000f59b00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000023b4a R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010 FS: 00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0 Call Trace: <TASK> ? show_regs+0x6d/0x80 ? die+0x37/0xa0 ? do_trap+0xd4/0xf0 ? • https://git.kernel.org/stable/c/c1d6a22b7219bd52c66e9e038a282ba79f04be1f https://git.kernel.org/stable/c/828862071a6ca0c52655e6e62ac7abfef3e5c578 https://git.kernel.org/stable/c/9cbd1dae842737bfafa4b10a87909fa209dde250 •
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 • 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 •
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: -EPSS: 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 •