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: 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: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48866 – HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts
https://notcve.org/view.php?id=CVE-2022-48866
In the Linux kernel, the following vulnerability has been resolved: HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug. The root case is in missing validation check of actual number of endpoints. Code should not blindly access usb_host_interface::endpoint array, since it may contain less endpoints than code expects. Fix it by adding missing validaion check and print an error if number of endpoints do not match expected number En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: hid-thrustmaster: corrige la lectura OOB en Thrustmaster_interrupts Syzbot informó un error de lectura fuera de los límites en Thrustmaster_probe(). El caso raíz es la falta de verificación de validación del número real de endpoints. El código no debe acceder ciegamente a usb_host_interface::endpoint array, ya que puede contener menos endpoints de los que espera el código. Solucionelo agregando una verificación de validación faltante e imprima un error si el número de endpoints no coincide con el número esperado • https://git.kernel.org/stable/c/c49c33637802a2c6957a78119eb8be3b055dd9e9 https://git.kernel.org/stable/c/3ffbe85cda7f523dad896bae08cecd8db8b555ab https://git.kernel.org/stable/c/56185434e1e50acecee56d8f5850135009b87947 https://git.kernel.org/stable/c/fc3ef2e3297b3c0e2006b5d7b3d66965e3392036 https://access.redhat.com/security/cve/CVE-2022-48866 https://bugzilla.redhat.com/show_bug.cgi?id=2298640 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48865 – tipc: fix kernel panic when enabling bearer
https://notcve.org/view.php?id=CVE-2022-48865
In the Linux kernel, the following vulnerability has been resolved: tipc: fix kernel panic when enabling bearer When enabling a bearer on a node, a kernel panic is observed: [ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc] ... [ 4.520030] Call Trace: [ 4.520689] <IRQ> [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc] [ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc] [ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc] [ 4.525292] tipc_rcv+0x5da/0x730 [tipc] [ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0 [ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc] [ 4.528737] __netif_receive_skb_list_core+0x20b/0x260 [ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0 [ 4.531450] ? dev_gro_receive+0x4c2/0x680 [ 4.532512] napi_complete_done+0x6f/0x180 [ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net] ... The node in question is receiving activate messages in another thread after changing bearer status to allow message sending/ receiving in current thread: thread 1 | thread 2 -------- | -------- | tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } | Monitoring pointer in thread 2 is dereferenced before monitoring data is allocated in thread 1. • https://git.kernel.org/stable/c/35c55c9877f8de0ab129fa1a309271d0ecc868b9 https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5 https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71 https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94 https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3 • CWE-476: NULL Pointer Dereference •