CVSS: 6.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35843 – iommu/vt-d: Use device rbtree in iopf reporting path
https://notcve.org/view.php?id=CVE-2024-35843
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: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35831 – io_uring: Fix release of pinned pages when __io_uaddr_map fails
https://notcve.org/view.php?id=CVE-2024-35831
In the Linux kernel, the following vulnerability has been resolved: io_uring: Fix release of pinned pages when __io_uaddr_map fails Looking at the error path of __io_uaddr_map, if we fail after pinning the pages for any reasons, ret will be set to -EINVAL and the error handler won't properly release the pinned pages. I didn't manage to trigger it without forcing a failure, but it can happen in real life when memory is heavily fragmented. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corregida la liberación de páginas fijadas cuando falla __io_uaddr_map. Mirando la ruta de error de __io_uaddr_map, si fallamos después de fijar las páginas por cualquier motivo, ret se establecerá en -EINVAL y el El controlador de errores no libera correctamente las páginas fijadas. No logré activarlo sin forzar un fallo, pero puede suceder en la vida real cuando la memoria está muy fragmentada. A flaw was found in the `io_uring` subsystem in the Linux kernel, where pinned pages are not properly released if the `__io_uaddr_map` function fails. • https://git.kernel.org/stable/c/223ef474316466e9f61f6e0064f3a6fe4923a2c5 https://git.kernel.org/stable/c/3f3164ce6396138747984ee9e61158e248246300 https://git.kernel.org/stable/c/0b6f39c175ba5f0ef72bdb3b9d2a06ad78621d62 https://git.kernel.org/stable/c/712e2c8415f55a4a4ddaa98a430b87f624109f69 https://git.kernel.org/stable/c/4d376d7ad62b6a8e8dfff56b559d9d275e5b9b3a https://git.kernel.org/stable/c/67d1189d1095d471ed7fa426c7e384a7140a5dd7 https://access.redhat.com/security/cve/CVE-2024-35831 https://bugzilla.redhat.com/show_bug.cgi?id=2281173 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35830 – media: tc358743: register v4l2 async device only after successful setup
https://notcve.org/view.php?id=CVE-2024-35830
In the Linux kernel, the following vulnerability has been resolved: media: tc358743: register v4l2 async device only after successful setup Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: tc358743: registre el dispositivo asíncrono v4l2 solo después de una configuración exitosa Asegúrese de que el dispositivo se haya configurado correctamente antes de registrar el dispositivo asíncrono v4l2, permitiendo así el acceso al espacio de usuario. • https://git.kernel.org/stable/c/4c5211a100399c3823563193dd881dcb3b7d24fc https://git.kernel.org/stable/c/17c2650de14842c25c569cbb2126c421489a3a24 https://git.kernel.org/stable/c/daf21394f9898fb9f0698c3e50de08132d2164e6 https://git.kernel.org/stable/c/610f20e5cf35ca9c0992693cae0dd8643ce932e7 https://git.kernel.org/stable/c/b8505a1aee8f1edc9d16d72ae09c93de086e2a1a https://git.kernel.org/stable/c/8ba8db9786b55047df5ad3db3e01dd886687a77d https://git.kernel.org/stable/c/edbb3226c985469a2f8eb69885055c9f5550f468 https://git.kernel.org/stable/c/c915c46a25c3efb084c4f5e69a053d7f7 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35829 – drm/lima: fix a memleak in lima_heap_alloc
https://notcve.org/view.php?id=CVE-2024-35829
In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix a memleak in lima_heap_alloc When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/lima: corregida una fuga de mem en lima_heap_alloc Cuando falla lima_vm_map_bo, es necesario desasignar los recursos o habrá fugas de memoria. • https://git.kernel.org/stable/c/6aebc51d7aeff5a30d86485f320f0c871b5f23a4 https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7 https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35828 – wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
https://notcve.org/view.php?id=CVE-2024-35828
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: libertas: arreglados algunas memleaks en lbs_allocate_cmd_buffer() En la declaración for de lbs_allocate_cmd_buffer(), si falló la asignación de cmdarray[i].cmdbuf, tanto cmdarray como cmdarray[i] Es necesario liberar ].cmdbuf. De lo contrario, habrá fugas de memoria en lbs_allocate_cmd_buffer(). • https://git.kernel.org/stable/c/876c9d3aeb989cf1961f2c228d309ba5dcfb1172 https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186 https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7 https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2 https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9 https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3 https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23ed •