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: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26686 – fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
https://notcve.org/view.php?id=CVE-2024-26686
In the Linux kernel, the following vulnerability has been resolved: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc: do_task_stat: use sig->stats_lock para recopilar las estadísticas de subprocesos/hijos lock_task_sighand() puede desencadenar un bloqueo completo. Si los subprocesos NR_CPUS llaman a do_task_stat() al mismo tiempo y el proceso tiene NR_THREADS, girará con irqs deshabilitados O(NR_CPUS * NR_THREADS) tiempo. Cambie do_task_stat() para usar sig->stats_lock para recopilar las estadísticas fuera de ->sección protegida siglock, en el caso probable de que este código se ejecute sin bloqueo. • https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071 https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305 https://access.redhat.com/security/cve/CVE-2024-26686 https://bugzilla.redhat.com/show_bug.cgi?id=2273109 • CWE-413: Improper Resource Locking •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52638 – can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock
https://notcve.org/view.php?id=CVE-2023-52638
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: previene el interbloqueo cambiando j1939_socks_lock a rwlock Los siguientes 3 bloqueos competirían entre sí, causando la situación de interbloqueo en el informe de error de Syzbot: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A Una solución razonable es cambiar j1939_socks_lock por un rwlock, ya que en las raras situaciones en las que se requiere un bloqueo de escritura para la lista vinculada que j1939_socks_lock está protegiendo, el código no intenta adquirir más bloqueos. Esto rompería la dependencia del bloqueo circular, donde, por ejemplo, el subproceso actual ya bloquea j1939_socks_lock e intenta adquirir sk_session_queue_lock y, al mismo tiempo, otro subproceso intenta adquirir j1939_socks_lock mientras mantiene sk_session_queue_lock. NOTA: Este parche no soluciona el error unregister_netdevice informado por Syzbot; en cambio, resuelve una situación de punto muerto para prepararse para uno o más parches adicionales para corregir el error Syzbot, que parece ser un problema de conteo de referencias dentro del código base j1939. [mkl: eliminar cambio de nueva línea no relacionado] A vulnerability was found in the Linux kernel's Controller Area Network (CAN) protocol, within the J1939 protocol implementation. • https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170 https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284 https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d https://access.redhat.com/security/cve/CVE-2023-52638 https://bugzilla.redhat.com/show_bug.cgi?id=2273082 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26677 – rxrpc: Fix delayed ACKs to not set the reference serial number
https://notcve.org/view.php?id=CVE-2024-26677
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige los ACK retrasados para no establecer el número de serie de referencia. Se corrige la construcción de los ACK retrasados para no establecer el número de serie de referencia, ya que no se pueden usar como referencia RTT. • https://git.kernel.org/stable/c/17926a79320afa9b95df6b977b40cca6d8713cea https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2 https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef •