CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41012 – filelock: Remove locks reliably when fcntl/close race is detected
https://notcve.org/view.php?id=CVE-2024-41012
In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: filelock: Elimina bloqueos de manera confiable cuando se detecta fcntl/close race Cuando fcntl_setlk() corre con close(), elimina el bloqueo creado con do_lock_file_wait(). Sin embargo, los LSM pueden permitir el primer do_lock_file_wait() que creó el bloqueo y al mismo tiempo negar el segundo do_lock_file_wait() que intenta eliminar el bloqueo. Por separado, posix_lock_file() también podría no eliminar un bloqueo debido a un fallo en la asignación de GFP_KERNEL (al dividir un rango por la mitad). • https://git.kernel.org/stable/c/c293621bbf678a3d85e3ed721c3921c8a670610d https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250 https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235 https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240 https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22 https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3 https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763 https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-41011 – drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
https://notcve.org/view.php?id=CVE-2024-41011
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: no permite mapear la página MMIO HDP con páginas grandes. • https://git.kernel.org/stable/c/d8e408a82704c86ba87c3d58cfe69dcdb758aa07 https://git.kernel.org/stable/c/009c4d78bcf07c4ac2e3dd9f275b4eaa72b4f884 https://git.kernel.org/stable/c/f7276cdc1912325b64c33fcb1361952c06e55f63 https://git.kernel.org/stable/c/8ad4838040e5515939c071a0f511ce2661a0889d https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28 https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724 https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5 https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-41010 – bpf: Fix too early release of tcx_entry
https://notcve.org/view.php?id=CVE-2024-41010
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix too early release of tcx_entry Pedro Pinto and later independently also Hyunwoo Kim and Wongi Lee reported an issue that the tcx_entry can be released too early leading to a use after free (UAF) when an active old-style ingress or clsact qdisc with a shared tc block is later replaced by another ingress or clsact instance. Essentially, the sequence to trigger the UAF (one example) can be as follows: 1. A network namespace is created 2. An ingress qdisc is created. This allocates a tcx_entry, and &tcx_entry->miniq is stored in the qdisc's miniqp->p_miniq. At the same time, a tcf block with index 1 is created. 3. chain0 is attached to the tcf block. chain0 must be connected to the block linked to the ingress qdisc to later reach the function tcf_chain0_head_change_cb_del() which triggers the UAF. 4. • https://git.kernel.org/stable/c/e420bed025071a623d2720a92bc2245c84757ecb https://git.kernel.org/stable/c/230bb13650b0f186f540500fd5f5f7096a822a2a https://git.kernel.org/stable/c/f61ecf1bd5b562ebfd7d430ccb31619857e80857 https://git.kernel.org/stable/c/1cb6f0bae50441f4b4b32a28315853b279c7404e • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41009 – bpf: Fix overrunning reservations in ringbuf
https://notcve.org/view.php?id=CVE-2024-41009
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. • https://git.kernel.org/stable/c/457f44363a8894135c85b7a9afd2bd8196db24ab https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4 https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686 https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069 https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225 https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881 https://access.redhat.com/security/cve/CVE-2024-41009 • CWE-121: Stack-based Buffer Overflow CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2023-52886 – USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
https://notcve.org/view.php?id=CVE-2023-52886
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. • https://git.kernel.org/stable/c/218925bfd5d1436e337c4f961e9c149fbe32de6d https://git.kernel.org/stable/c/77358093331e9769855140bf94a3f00ecdcf4bb1 https://git.kernel.org/stable/c/c87fb861ec185fdc578b4fdc6a05920b6a843840 https://git.kernel.org/stable/c/45bf39f8df7f05efb83b302c65ae3b9bc92b7065 https://git.kernel.org/stable/c/6badaf880edf51a2da7a439699676394dfdef3e5 https://git.kernel.org/stable/c/5f35b5d3bd6914c68f743741443dfd3a64b0e455 https://git.kernel.org/stable/c/a1e89c8b29d003a20ed2dae6bdae1598d1f23e42 https://git.kernel.org/stable/c/1bcb238c54a9c6dc4bded06b06ba7458a •