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: 8EXPL: 0CVE-2024-26696 – nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
https://notcve.org/view.php?id=CVE-2024-26696
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. • https://git.kernel.org/stable/c/1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0 https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46 https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6 https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32 https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28 https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca5447 •
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 •