CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26946 – kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address
https://notcve.org/view.php?id=CVE-2024-26946
In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes/x86: use copy_from_kernel_nofault() para leer desde una dirección no segura Lea desde una dirección no segura con copy_from_kernel_nofault() en arch_adjust_kprobe_addr() porque esta función se usa antes de verificar que la dirección esté en texto O no. El bot Syzcaller encontró un error e informó el caso si el usuario especifica un área de datos inaccesible, arch_adjust_kprobe_addr() provocará un pánico en el kernel. [ mingo: Aclaró el comentario. ] An unsafe read function was found in arch/x86/kernel/kprobes/core.c in the Linux kernel . • https://git.kernel.org/stable/c/cc66bb91457827f62e2b6cb2518666820f0a6c48 https://git.kernel.org/stable/c/6417684315087904fffe8966d27ca74398c57dd6 https://git.kernel.org/stable/c/f13edd1871d4fb4ab829aff629d47914e251bae3 https://git.kernel.org/stable/c/20fdb21eabaeb8f78f8f701f56d14ea0836ec861 https://git.kernel.org/stable/c/b69f577308f1070004cafac106dd1a44099e5483 https://git.kernel.org/stable/c/4e51653d5d871f40f1bd5cf95cc7f2d8b33d063b https://access.redhat.com/security/cve/CVE-2024-26946 https://bugzilla.redhat.com/show_bug.cgi?id=2278206 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26944 – btrfs: zoned: fix use-after-free in do_zone_finish()
https://notcve.org/view.php?id=CVE-2024-26944
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? • https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57 https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26943 – nouveau/dmem: handle kcalloc() allocation failure
https://notcve.org/view.php?id=CVE-2024-26943
In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/dmem: maneja el error de asignación de kcalloc() El kcalloc() en nouveau_dmem_evict_chunk() devolverá nulo si la memoria física se ha agotado. • https://git.kernel.org/stable/c/249881232e1471d28b68f9a3829acc14d150cf5d https://git.kernel.org/stable/c/9acfd8b083a0ffbd387566800d89f55058a68af2 https://git.kernel.org/stable/c/2a84744a037b8a511d6a9055f3defddc28ff4a4d https://git.kernel.org/stable/c/5e81773757a95fc298e96cfd6d4700f07b6192a2 https://git.kernel.org/stable/c/3e82f7383e0b82a835e6b6b06a348b2bc4e2c2ee https://git.kernel.org/stable/c/16e87fe23d4af6df920406494ced5c0f4354567b •
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 •