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: -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/ •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35949 – btrfs: make sure that WRITTEN is set on all metadata blocks
https://notcve.org/view.php?id=CVE-2024-35949
In the Linux kernel, the following vulnerability has been resolved: btrfs: make sure that WRITTEN is set on all metadata blocks We previously would call btrfs_check_leaf() if we had the check integrity code enabled, which meant that we could only run the extended leaf checks if we had WRITTEN set on the header flags. This leaves a gap in our checking, because we could end up with corruption on disk where WRITTEN isn't set on the leaf, and then the extended leaf checks don't get run which we rely on to validate all of the item pointers to make sure we don't access memory outside of the extent buffer. However, since 732fab95abe2 ("btrfs: check-integrity: remove CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only ever call it on blocks that are being written out, and thus have WRITTEN set, or that are being read in, which should have WRITTEN set. Add checks to make sure we have WRITTEN set appropriately, and then make sure __btrfs_check_leaf() always does the item checking. This will protect us from file systems that have been corrupted and no longer have WRITTEN set on some of the blocks. This was hit on a crafted image tweaking the WRITTEN bit and reported by KASAN as out-of-bound access in the eb accessors. The example is a dir item at the end of an eb. [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2 [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f] [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1 [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0 [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206 [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0 [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748 [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9 [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8 [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000 [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0 [2.621] Call Trace: [2.621] <TASK> [2.621] ? show_regs+0x74/0x80 [2.621] ? die_addr+0x46/0xc0 [2.621] ? • https://git.kernel.org/stable/c/ef3ba8ce8cf7075b716aa4afcefc3034215878ee https://git.kernel.org/stable/c/e03418abde871314e1a3a550f4c8afb7b89cb273 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534 •