CVE-2024-26621 – mm: huge_memory: don't force huge page alignment on 32 bit
https://notcve.org/view.php?id=CVE-2024-26621
In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don't force huge page alignment on 32 bit commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: huge_memory: no forzar una alineación de página enorme en el commit de 32 bits efa7df3e3bb5 ("mm: alinear asignaciones anónimas más grandes en los límites de THP") causó dos problemas [1] [2] informado en un sistema de 32 bits o espacio de usuario compatible. No tiene mucho sentido forzar una gran alineación de páginas en un sistema de 32 bits debido al espacio limitado de direcciones virtuales. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD- sQ@mail.gmail.com/ • https://git.kernel.org/stable/c/1854bc6e2420472676c5c90d3d6b15f6cd640e40 https://git.kernel.org/stable/c/87632bc9ecff5ded93433bc0fca428019bdd1cfe https://git.kernel.org/stable/c/6ea9aa8d97e6563676094cb35755884173269555 https://git.kernel.org/stable/c/7432376c913381c5f24d373a87ff629bbde94b47 https://git.kernel.org/stable/c/4ef9ad19e17676b9ef071309bc62020e2373705d http://www.openwall.com/lists/oss-security/2024/07/08/3 http://www.openwall.com/lists/oss-security/2024/07/08/4 http://www.openwall.com/lists/oss-security/2024/07 •
CVE-2024-26620 – s390/vfio-ap: always filter entire AP matrix
https://notcve.org/view.php?id=CVE-2024-26620
In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: always filter entire AP matrix The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or domain is assigned to the mdev. The purpose of the function is to update the guest's AP configuration by filtering the matrix of adapters and domains assigned to the mdev. When an adapter or domain is assigned, only the APQNs associated with the APID of the new adapter or APQI of the new domain are inspected. If an APQN does not reference a queue device bound to the vfio_ap device driver, then it's APID will be filtered from the mdev's matrix when updating the guest's AP configuration. Inspecting only the APID of the new adapter or APQI of the new domain will result in passing AP queues through to a guest that are not bound to the vfio_ap device driver under certain circumstances. Consider the following: guest's AP configuration (all also assigned to the mdev's matrix): 14.0004 14.0005 14.0006 16.0004 16.0005 16.0006 unassign domain 4 unbind queue 16.0005 assign domain 4 When domain 4 is re-assigned, since only domain 4 will be inspected, the APQNs that will be examined will be: 14.0004 16.0004 Since both of those APQNs reference queue devices that are bound to the vfio_ap device driver, nothing will get filtered from the mdev's matrix when updating the guest's AP configuration. • https://git.kernel.org/stable/c/48cae940c31d2407d860d87c41d5f9871c0521db https://git.kernel.org/stable/c/d6b8d034b576f406af920a7bee81606c027b24c6 https://git.kernel.org/stable/c/c69d821197611678533fb3eb784fc823b921349a https://git.kernel.org/stable/c/cdd134d56138302976685e6c7bc4755450b3880e https://git.kernel.org/stable/c/850fb7fa8c684a4c6bf0e4b6978f4ddcc5d43d11 •
CVE-2024-26619 – riscv: Fix module loading free order
https://notcve.org/view.php?id=CVE-2024-26619
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix module loading free order Reverse order of kfree calls to resolve use-after-free error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige el orden libre de carga del módulo. Orden inverso de las llamadas kfree para resolver el error de use-after-free. • https://git.kernel.org/stable/c/d8792a5734b0f3e58b898c2e2f910bfac48e9ee3 https://git.kernel.org/stable/c/2fa79badf4bfeffda6b5032cf62b828486ec9a99 https://git.kernel.org/stable/c/78996eee79ebdfe8b6f0e54cb6dcc792d5129291 •
CVE-2024-26618 – arm64/sme: Always exit sme_alloc() early with existing storage
https://notcve.org/view.php?id=CVE-2024-26618
In the Linux kernel, the following vulnerability has been resolved: arm64/sme: Always exit sme_alloc() early with existing storage When sme_alloc() is called with existing storage and we are not flushing we will always allocate new storage, both leaking the existing storage and corrupting the state. Fix this by separating the checks for flushing and for existing storage as we do for SVE. Callers that reallocate (eg, due to changing the vector length) should call sme_free() themselves. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/sme: salir siempre de sme_alloc() antes de tiempo con el almacenamiento existente. Cuando se llama a sme_alloc() con el almacenamiento existente y no estamos vaciando, siempre asignaremos nuevo almacenamiento, y ambos filtrarán el almacenamiento existente, almacenamiento y corrupción del estado. Solucione este problema separando los controles de descarga y de almacenamiento existente como lo hacemos con SVE. • https://git.kernel.org/stable/c/5d0a8d2fba50e9c07cde4aad7fba28c008b07a5b https://git.kernel.org/stable/c/21614ba60883eb93b99a7ee4b41cb927f93b39ae https://git.kernel.org/stable/c/e01af8e26c23a08625a3dd6c8c472a1752d76cce https://git.kernel.org/stable/c/569156e4fa347237f8fa2a7e935d860109c55ac4 https://git.kernel.org/stable/c/814af6b4e6000e574e74d92197190edf07cc3680 https://git.kernel.org/stable/c/dc7eb8755797ed41a0d1b5c0c39df3c8f401b3d9 •
CVE-2024-26617 – fs/proc/task_mmu: move mmu notification mechanism inside mm lock
https://notcve.org/view.php?id=CVE-2024-26617
In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: move mmu notification mechanism inside mm lock Move mmu notification mechanism inside mm lock to prevent race condition in other components which depend on it. The notifier will invalidate memory range. Depending upon the number of iterations, different memory ranges would be invalidated. The following warning would be removed by this patch: WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 There is no behavioural and performance change with this patch when there is no component registered with the mmu notifier. [akpm@linux-foundation.org: narrow the scope of `range', per Sean] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc/task_mmu: mover el mecanismo de notificación mmu dentro del bloqueo mm Mueva el mecanismo de notificación mmu dentro del bloqueo mm para evitar condiciones de ejecución en otros componentes que dependen de él. • https://git.kernel.org/stable/c/52526ca7fdb905a768a93f8faa418e9b988fc34b https://git.kernel.org/stable/c/05509adf297924f51e1493aa86f9fcde1433ed80 https://git.kernel.org/stable/c/4cccb6221cae6d020270606b9e52b1678fc8b71a •