CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52583 – ceph: fix deadlock or deadcode of misusing dget()
https://notcve.org/view.php?id=CVE-2023-52583
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ceph: corrige el punto muerto o el código muerto por uso incorrecto de dget() El orden de bloqueo es incorrecto entre denty y su padre, siempre debemos asegurarnos de que el padre obtenga el bloqueo primero. Pero dado que este código muerto nunca se usa y el directorio principal siempre será configurado por quienes llaman, simplemente eliminémoslo. • https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6 https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980 https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3 https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160 https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67 https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26622 – tomoyo: fix UAF write bug in tomoyo_write_control()
https://notcve.org/view.php?id=CVE-2024-26622
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tomoyo: corrige el error de escritura UAF en tomoyo_write_control() Dado que tomoyo_write_control() actualiza head->write_buf cuando se solicita write() de líneas largas, necesitamos recuperar head->write_buf después head->io_sem se mantiene. De lo contrario, las solicitudes de escritura () simultáneas pueden causar problemas de use-after-free-write y de doble liberación. • https://git.kernel.org/stable/c/bd03a3e4c9a9df0c6b007045fa7fc8889111a478 https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824 https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711 https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-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&# •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-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 •
CVSS: 6.0EPSS: 0%CPEs: 5EXPL: 0CVE-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 https://access.redhat.com/security/cve/CVE-2024-26618 https://bugzilla.redhat.com/show_bug.cgi?id=2269192 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •