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: 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 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-39481 – media: mc: Fix graph walk in media_pipeline_start
https://notcve.org/view.php?id=CVE-2024-39481
In the Linux kernel, the following vulnerability has been resolved: media: mc: Fix graph walk in media_pipeline_start The graph walk tries to follow all links, even if they are not between pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link. Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK links. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mc: corrige el recorrido del gráfico en media_pipeline_start El recorrido del gráfico intenta seguir todos los enlaces, incluso si no están entre pads. Esto provoca un bloqueo, por ejemplo, con un enlace MEDIA_LNK_FL_ANCILLARY_LINK. Solucione este problema permitiendo que la caminata continúe solo para los enlaces MEDIA_LNK_FL_DATA_LINK. • https://git.kernel.org/stable/c/ae219872834a32da88408a92a4b4745c11f5a7ce https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376 https://git.kernel.org/stable/c/e80d9db99b7b6c697d8d952dfd25c3425cf61499 https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2 https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39480 – kdb: Fix buffer overflow during tab-complete
https://notcve.org/view.php?id=CVE-2024-39480
In the Linux kernel, the following vulnerability has been resolved: kdb: Fix buffer overflow during tab-complete Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kdb: corrige el desbordamiento del búfer durante la finalización de tabulación Actualmente, cuando el usuario intenta completar el símbolo con la tecla Tab, kdb usará strncpy() para insertar el símbolo completado en el búfer de comando. Desafortunadamente, pasa el tamaño del búfer de origen en lugar del destino a strncpy() con resultados predeciblemente horribles. Lo más obvio es que si el búfer de comando ya está lleno pero cp, la posición del cursor, está en el medio del búfer, entonces escribiremos más allá del final del búfer proporcionado. • https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992 https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96 https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33 https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7 https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5 https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7 https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3c • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39479 – drm/i915/hwmon: Get rid of devm
https://notcve.org/view.php?id=CVE-2024-39479
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. • https://git.kernel.org/stable/c/cfa73607eb21a4ce1d6294a2c5733628897b48a2 https://git.kernel.org/stable/c/ce5a22d22db691d14516c3b8fdbf69139eb2ea8f https://git.kernel.org/stable/c/5bc9de065b8bb9b8dd8799ecb4592d0403b54281 • CWE-400: Uncontrolled Resource Consumption •