Page 204 of 2864 results (0.007 seconds)

CVSS: 6.8EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. • https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15 https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a https://access.redhat.com/security/cve/CVE-2024-35843 https://bugzilla.redhat.com/show_bug.cgi?id=2281276 • CWE-416: Use After Free •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ACPI: video: check for error while searching for backlight device parent If acpi_get_parent() called in acpi_video_dev_register_backlight() fails, for example, because acpi_ut_acquire_mutex() fails inside acpi_get_parent), this can lead to incorrect (uninitialized) acpi_parent handle being passed to acpi_get_pci_dev() for detecting the parent pci device. Check acpi_get_parent() result and set parent device only in case of success. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: vídeo: comprueba si hay errores al buscar el dispositivo de retroiluminación principal. Si la llamada acpi_get_parent() en acpi_video_dev_register_backlight() fallo, por ejemplo, porque acpi_ut_acquire_mutex() fallo dentro de acpi_get_parent), esto puede provocar que se pase el identificador acpi_parent incorrecto (no inicializado) a acpi_get_pci_dev() para detectar el dispositivo pci principal. Verifique el resultado de acpi_get_parent() y configure el dispositivo principal solo en caso de éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/9661e92c10a9775243c1ecb73373528ed8725a10 https://git.kernel.org/stable/c/556f02699d33c1f40b1b31bd25828ce08fa165d8 https://git.kernel.org/stable/c/1e3a2b9b4039bb4d136dca59fb31e06465e056f3 https://git.kernel.org/stable/c/c4e1a0ef0b4782854c9b77a333ca912b392bed2f https://git.kernel.org/stable/c/3a370502a5681986f9828e43be75ce26c6ab24af https://git.kernel.org/stable/c/2124c5bc22948fc4d09a23db4a8acdccc7d21e95 https://git.kernel.org/stable/c/39af144b6d01d9b40f52e5d773e653957e6c379c https://git.kernel.org/stable/c/72884ce4e10417b1233b614bf134da852 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Proteger los límites de la pila contra el desbordamiento de 32 bits. • https://git.kernel.org/stable/c/ad140fc856f0b1d5e2215bcb6d0cc247a86805a2 https://git.kernel.org/stable/c/e5ad9ecb84405637df82732ee02ad741a5f782a6 https://git.kernel.org/stable/c/1d38a9ee81570c4bd61f557832dead4d6f816760 https://access.redhat.com/security/cve/CVE-2023-52676 https://bugzilla.redhat.com/show_bug.cgi?id=2281332 •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: clear BM pool before initialization Register value persist after booting the kernel using kexec which results in kernel panic. Thus clear the BM pool registers before initialisation to fix the issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mvpp2: borre el grupo de BM antes de la inicialización. El valor del registro persiste después de iniciar el kernel usando kexec, lo que genera pánico en el kernel. Por lo tanto, borre los registros del grupo BM antes de la inicialización para solucionar el problema. • https://git.kernel.org/stable/c/3f518509dedc99f0b755d2ce68d24f610e3a005a https://git.kernel.org/stable/c/83f99138bf3b396f761600ab488054396fb5768f https://git.kernel.org/stable/c/af47faa6d3328406038b731794e7cf508c71affa https://git.kernel.org/stable/c/cec65f09c47d8c2d67f2bcad6cf05c490628d1ec https://git.kernel.org/stable/c/938729484cfa535e9987ed0f86f29a2ae3a8188b https://git.kernel.org/stable/c/dc77f6ab5c3759df60ff87ed24f4d45df0f3b4c4 https://git.kernel.org/stable/c/9f538b415db862e74b8c5d3abbccfc1b2b6caa38 https://lists.debian.org/debian-lts-announce/2024/06/ •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a debugfs null pointer error [WHY & HOW] Check whether get_subvp_en() callback exists before calling it. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige un error de puntero null de debugfs [POR QUÉ Y CÓMO] Verifique si la devolución de llamada get_subvp_en() existe antes de llamarla. • https://git.kernel.org/stable/c/43235db21fc23559f50a62f8f273002eeb506f5a https://git.kernel.org/stable/c/efb91fea652a42fcc037d2a9ef4ecd1ffc5ff4b7 •