CVSS: 5.9EPSS: 0%CPEs: 1EXPL: 0CVE-2024-35957 – iommu/vt-d: Fix WARN_ON in iommu probe path
https://notcve.org/view.php?id=CVE-2024-35957
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix WARN_ON in iommu probe path Commit 1a75cc710b95 ("iommu/vt-d: Use rbtree to track iommu probed devices") adds all devices probed by the iommu driver in a rbtree indexed by the source ID of each device. It assumes that each device has a unique source ID. This assumption is incorrect and the VT-d spec doesn't state this requirement either. The reason for using a rbtree to track devices is to look up the device with PCI bus and devfunc in the paths of handling ATS invalidation time out error and the PRI I/O page faults. Both are PCI ATS feature related. Only track the devices that have PCI ATS capabilities in the rbtree to avoid unnecessary WARN_ON in the iommu probe path. Otherwise, on some platforms below kernel splat will be displayed and the iommu probe results in failure. WARNING: CPU: 3 PID: 166 at drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90 Call Trace: <TASK> ? • https://git.kernel.org/stable/c/c618d446f1d64bdc9e426bab5e8619f224cde2ae https://git.kernel.org/stable/c/fba8ca3e6f608b92e54271fdbd3ce569361939fc https://git.kernel.org/stable/c/89436f4f54125b1297aec1f466efd8acb4ec613d https://access.redhat.com/security/cve/CVE-2024-35957 https://bugzilla.redhat.com/show_bug.cgi?id=2281927 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35956 – btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
https://notcve.org/view.php?id=CVE-2024-35956
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction. However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. • https://git.kernel.org/stable/c/e85fde5162bf1b242cbd6daf7dba0f9b457d592b https://git.kernel.org/stable/c/2978cb474745b2d93c263008d265e89985706094 https://git.kernel.org/stable/c/14431815a4ae4bcd7c7a68b6a64c66c7712d27c9 https://git.kernel.org/stable/c/6c95336f5d8eb9ab79cd7306d71b6d0477363f8c https://git.kernel.org/stable/c/74e97958121aa1f5854da6effba70143f051b0cd •
CVSS: 8.8EPSS: 0%CPEs: 11EXPL: 0CVE-2024-35955 – kprobes: Fix possible use-after-free issue on kprobe registration
https://notcve.org/view.php?id=CVE-2024-35955
In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kprobes: soluciona un posible problema de use after free en el registro de kprobe Al descargar un módulo, su estado cambia MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. • https://git.kernel.org/stable/c/1c836bad43f3e2ff71cc397a6e6ccb4e7bd116f8 https://git.kernel.org/stable/c/6a119c1a584aa7a2c6216458f1f272bf1bc93a93 https://git.kernel.org/stable/c/2a49b025c36ae749cee7ccc4b7e456e02539cdc3 https://git.kernel.org/stable/c/a1edb85e60fdab1e14db63ae8af8db3f0d798fb6 https://git.kernel.org/stable/c/28f6c37a2910f565b4f5960df52b2eccae28c891 https://git.kernel.org/stable/c/4262b6eb057d86c7829168c541654fe0d48fdac8 https://git.kernel.org/stable/c/97e813e6a143edf4208e15c72199c495ed80cea5 https://git.kernel.org/stable/c/16a544f1e013ba0660612f3fe35393b14 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35954 – scsi: sg: Avoid sg device teardown race
https://notcve.org/view.php?id=CVE-2024-35954
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Avoid sg device teardown race sg_remove_sfp_usercontext() must not use sg_device_destroy() after calling scsi_device_put(). sg_device_destroy() is accessing the parent scsi_device request_queue which will already be set to NULL when the preceding call to scsi_device_put() removed the last reference to the parent scsi_device. The resulting NULL pointer exception will then crash the kernel. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: sg: Evite la ejecución de desmontaje del dispositivo sg sg_remove_sfp_usercontext() no debe usar sg_device_destroy() después de llamar a scsi_device_put(). sg_device_destroy() está accediendo al scsi_device principal request_queue que ya estará configurado en NULL cuando la llamada anterior a scsi_device_put() eliminó la última referencia al scsi_device principal. La excepción de puntero NULL resultante bloqueará el kernel. • https://git.kernel.org/stable/c/db59133e927916d8a25ee1fd8264f2808040909d https://git.kernel.org/stable/c/4cc664e59bf2553771e4c9e90f758f7434cfdc22 https://git.kernel.org/stable/c/46af9047523e2517712ae8e71d984286c626e022 https://git.kernel.org/stable/c/b0d1ebcc1a9560e494ea9b3ee808540db26c5086 https://git.kernel.org/stable/c/27f58c04a8f438078583041468ec60597841284d https://access.redhat.com/security/cve/CVE-2024-35954 https://bugzilla.redhat.com/show_bug.cgi?id=2281933 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35953 – accel/ivpu: Fix deadlock in context_xa
https://notcve.org/view.php?id=CVE-2024-35953
In the Linux kernel, the following vulnerability has been resolved: accel/ivpu: Fix deadlock in context_xa ivpu_device->context_xa is locked both in kernel thread and IRQ context. It requires XA_FLAGS_LOCK_IRQ flag to be passed during initialization otherwise the lock could be acquired from a thread and interrupted by an IRQ that locks it for the second time causing the deadlock. This deadlock was reported by lockdep and observed in internal tests. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: accel/ivpu: corrige el punto muerto en context_xa ivpu_device->context_xa está bloqueado tanto en el subproceso del kernel como en el contexto IRQ. Requiere que se pase el indicador XA_FLAGS_LOCK_IRQ durante la inicialización; de lo contrario, el bloqueo podría adquirirse de un subproceso e interrumpirse mediante una IRQ que lo bloquee por segunda vez, provocando el punto muerto. Este punto muerto fue informado por lockdep y observado en pruebas internas. • https://git.kernel.org/stable/c/35b137630f08d913fc2e33df33ccc2570dff3f7d https://git.kernel.org/stable/c/d43e11d9c7fcb16f18bd46ab2556c2772ffc5775 https://git.kernel.org/stable/c/e6011411147209bc0cc14628cbc155356837e52a https://git.kernel.org/stable/c/fd7726e75968b27fe98534ccbf47ccd6fef686f3 •