CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26699 – drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr
https://notcve.org/view.php?id=CVE-2024-26699
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr [Why] There is a potential memory access violation while iterating through array of dcn35 clks. [How] Limit iteration per array size. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige el índice de matriz fuera de los límites en dcn35_clkmgr [Por qué] Existe una posible infracción de acceso a la memoria al iterar a través de una matriz de clks dcn35. [Cómo] Limitar la iteración por tamaño de matriz. • https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26697 – nilfs2: fix data corruption in dsync block recovery for small block sizes
https://notcve.org/view.php?id=CVE-2024-26697
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige la corrupción de datos en la recuperación de bloques dsync para tamaños de bloques pequeños La función auxiliar nilfs_recovery_copy_block() de nilfs_recovery_dsync_blocks(), que recupera datos de los registros creados por escrituras de sincronización de datos durante un montaje después un apagado incorrecto calcula incorrectamente el desplazamiento en la página al copiar los datos de reparación en la memoria caché de la página del archivo. En entornos donde el tamaño del bloque es menor que el tamaño de la página, esta falla puede causar corrupción de datos y pérdida de bytes de memoria no inicializados durante el proceso de recuperación. Solucione estos problemas corrigiendo este cálculo de desplazamiento de bytes en la página. • https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65 https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5 https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3 https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9 https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a61 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26691 – KVM: arm64: Fix circular locking dependency
https://notcve.org/view.php?id=CVE-2024-26691
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige la dependencia de bloqueo circular La regla dentro de kvm exige que vcpu->mutex se tome *dentro* de kvm->lock. La regla es violada por pkvm_create_hyp_vm() que adquiere el bloqueo kvm->mientras ya mantiene el bloqueo vcpu->mutex de kvm_vcpu_ioctl(). • https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228 https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26689 – ceph: prevent use-after-free in encode_cap_msg()
https://notcve.org/view.php?id=CVE-2024-26689
In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error. • https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214 https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77 https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139 https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7 https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26687 – xen/events: close evtchn after mapping cleanup
https://notcve.org/view.php?id=CVE-2024-26687
In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. • https://git.kernel.org/stable/c/d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44 https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3 https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5 https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4 https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c •