CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35965 – Bluetooth: L2CAP: Fix not validating setsockopt user input
https://notcve.org/view.php?id=CVE-2024-35965
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: L2CAP: solución que no valida la entrada del usuario de setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos. • https://git.kernel.org/stable/c/33575df7be6748292f88453f29319af6d639c5c8 https://git.kernel.org/stable/c/f13b04cf65a86507ff15a9bbf37969d25be3e2a0 https://git.kernel.org/stable/c/9d42f373391211c7c8af66a3a316533a32b8a607 https://git.kernel.org/stable/c/28234f8ab69c522ba447f3e041bbfbb284c5959a https://git.kernel.org/stable/c/8ee0c132a61df9723813c40e742dc5321824daa9 https://git.kernel.org/stable/c/4f3951242ace5efc7131932e2e01e6ac6baed846 •
CVSS: 9.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35960 – net/mlx5: Properly link new fs rules into the tree
https://notcve.org/view.php?id=CVE-2024-35960
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle. • https://git.kernel.org/stable/c/74491de937125d0c98c9b9c9208b4105717a3caa https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2 https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423 https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801 https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64 https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0 https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f • CWE-476: NULL Pointer Dereference •
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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35951 – drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
https://notcve.org/view.php?id=CVE-2024-35951
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Asunto: [PATCH] drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Si algunas páginas o la asignación de sgt fallaron, No deberíamos publicar la referencia de páginas que obtuvimos anteriormente, de lo contrario terminaremos con llamadas get/put_pages() desequilibradas. En su lugar, deberíamos dejar todo en su lugar y dejar que la función de liberación de BO se encargue de una limpieza adicional cuando se destruya el objeto, o dejar que el controlador de fallos lo intente nuevamente la próxima vez que se llame. • https://git.kernel.org/stable/c/187d2929206e6b098312c174ea873e4cedf5420d https://git.kernel.org/stable/c/31806711e8a4b75e09b1c43652f2a6420e6e1002 https://git.kernel.org/stable/c/e18070c622c63f0cab170348e320454728c277aa https://git.kernel.org/stable/c/1fc9af813b25e146d3607669247d0f970f5a87c3 http://www.openwall.com/lists/oss-security/2024/05/30/1 http://www.openwall.com/lists/oss-security/2024/05/30/2 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35950 – drm/client: Fully protect modes[] with dev->mode_config.mutex
https://notcve.org/view.php?id=CVE-2024-35950
In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: Protege completamente los modos[] con dev->mode_config.mutex. La matriz modes[] contiene punteros a los modos en las listas de modos de los conectores, que están protegidos por dev- >mode_config.mutex. Por lo tanto, necesitamos extender modes[] la misma protección o, cuando la usemos, es posible que los elementos ya estén apuntando a la memoria liberada/reutilizada. • https://git.kernel.org/stable/c/5a2f957e3c4553bbb100504a1acfeaeb33f4ca4e https://git.kernel.org/stable/c/41586487769eede64ab1aa6c65c74cbf76c12ef0 https://git.kernel.org/stable/c/d2dc6600d4e3e1453e3b1fb233e9f97e2a1ae949 https://git.kernel.org/stable/c/18c8cc6680ce938d0458859b6a08b4d34f7d8055 https://git.kernel.org/stable/c/04e018bd913d3d3336ab7d21c2ad31a9175fe984 https://git.kernel.org/stable/c/8ceb873d816786a7c8058f50d903574aff8d3764 https://git.kernel.org/stable/c/3eadd887dbac1df8f25f701e5d404d1b90fd0fea https://lists.debian.org/debian-lts-announce/2024/06/ •