CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39486 – drm/drm_file: Fix pid refcounting race
https://notcve.org/view.php?id=CVE-2024-39486
In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> filp->pid is supposed to be a refcounted pointer; however, before this patch, drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronize_rcu() operation while process B is between mutex_unlock() and get_pid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_file: corrige la ejecución de recuento de pid filp->pid se supone que es un puntero recontado; sin embargo, antes de este parche, drm_file_update_pid() solo incrementa el recuento de una estructura pid después de almacenar un puntero a ella en filp->pid y eliminar dev->filelist_mutex, haciendo posible la siguiente ejecución: proceso A proceso B ==== ===== ========= comenzar drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev- >filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() *** pid B alcanza refcount 0 y se libera aquí *** get_pid() *** UAF *** synchronize_rcu() put_pid() Hasta donde yo sé, esta ejecución solo puede ocurrir con CONFIG_PREEMPT_RCU=y porque requiere que RCU detecte un estado inactivo en el código que no llame explícitamente al programador. Esta ejecución conduce a use after free de una "estructura pid". Probablemente sea algo difícil de lograr porque el proceso A tiene que pasar por una operación synchronize_rcu() mientras que el proceso B está entre mutex_unlock() y get_pid(). Solucionelo asegurándose de que cuando se almacene en el archivo un puntero al pid de la tarea actual, se haya tomado una referencia adicional al pid. • https://git.kernel.org/stable/c/031ddd28008971cce0b5626379b910d0a05fb4dd https://git.kernel.org/stable/c/1c7a387ffef894b1ab3942f0482dac7a6e0a909c https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39485 – media: v4l: async: Properly re-initialise notifier entry in unregister
https://notcve.org/view.php?id=CVE-2024-39485
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Properly re-initialise notifier entry in unregister The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: v4l: async: Reinicializar correctamente la entrada del notificador al cancelar el registro Notifier_entry de un notificador no se reinicializa después de cancelar el registro del notificador. Esto lleva a que se dejen punteros colgando allí, así que use list_del_init() para devolver notifier_entry una lista vacía. • https://git.kernel.org/stable/c/b8ec754ae4c563f6aab8c0cb47aeb2eae67f1da3 https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66 https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a • CWE-665: Improper Initialization •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39484 – mmc: davinci: Don't strip remove function when driver is builtin
https://notcve.org/view.php?id=CVE-2024-39484
In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: davinci: no eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_MMC_DAVINCI=y. • https://git.kernel.org/stable/c/b4cff4549b7a8c5fc8b88e3493b6287555f0512c https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4 https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1 https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584 https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39483 – KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
https://notcve.org/view.php?id=CVE-2024-39483
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. • https://git.kernel.org/stable/c/fa4c027a7956f5e07697bfcb580d25eeb8471257 https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356 https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1 https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6 https://access.redhat.com/security/cve/CVE-2024-39483 https://bugzilla.redhat.com/show_bug.cgi?id=2295921 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39482 – bcache: fix variable length array abuse in btree_iter
https://notcve.org/view.php?id=CVE-2024-39482
In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: corrige el abuso de matriz de longitud variable en btree_iter btree_iter se usa de dos maneras: ya sea asignado en la pila con un tamaño fijo MAX_BSETS, o desde un mempool con un tamaño dinámico basado en el conjunto de caché específico. Anteriormente, la estructura tenía una matriz de longitud fija de tamaño MAX_BSETS que estaba indexada fuera de los límites para los iteradores de tamaño dinámico, lo que provoca que UBSAN se queje. Este parche utiliza el mismo enfoque que en sort_iter de bcachefs y divide el iterador en un btree_iter con un miembro de matriz flexible y un btree_iter_stack que incorpora un btree_iter así como una matriz de datos de longitud fija. • https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023 https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02 https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148 https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671 https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31 • CWE-770: Allocation of Resources Without Limits or Throttling •