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: 4.4EPSS: 0%CPEs: 1EXPL: 0CVE-2024-41008 – drm/amdgpu: change vm->task_info handling
https://notcve.org/view.php?id=CVE-2024-41008
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: change vm->task_info handling This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for task_info lifecycle management - amdgpu_vm_get_task_info: reference counts up task_info before returning this info - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm. This patch also does logistical changes required for existing usage of vm->task_info. V2: Do not block all the prints when task_info not found (Felix) V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for task_info - Do not duplicate the debug messages (ti vs no ti) - Get first reference of task_info in vm_init(), put last in vm_fini() V4: Fixed review comments from Felix - fix double reference increment in create_task_info - change amdgpu_vm_get_task_info_pasid - additional changes in amdgpu_gem.c while porting • https://git.kernel.org/stable/c/b8f67b9ddf4f8fe6dd536590712b5912ad78f99c https://access.redhat.com/security/cve/CVE-2024-41008 https://bugzilla.redhat.com/show_bug.cgi?id=2298079 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41007 – tcp: avoid too many retransmit packets
https://notcve.org/view.php?id=CVE-2024-41007
In the Linux kernel, the following vulnerability has been resolved: tcp: avoid too many retransmit packets If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'. The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: evitar demasiados paquetes de retransmisión Si un socket TCP está usando TCP_USER_TIMEOUT y el otro par retrajo su ventana a cero, tcp_retransmit_timer() puede retransmitir un paquete cada dos santiamén (2 ms). para HZ=1000), durante aproximadamente 4 minutos después de que TCP_USER_TIMEOUT haya 'expirado'. La solución es asegurarse de que tcp_rtx_probe0_timed_out() tenga en cuenta icsk->icsk_user_timeout. Antes de el commit culpable, el socket no expiraba después de icsk->icsk_user_timeout, sino que usaba un retroceso exponencial estándar para las retransmisiones. También vale la pena señalar que antes de commit e89688e3e978 ("net: tcp: fix unexcepted socket die cuando snd_wnd es 0"), el problema duraría 2 minutos en lugar de 4. • https://git.kernel.org/stable/c/b701a99e431db784714c32fc6b68123045714679 https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4 https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969 https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982 https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570 https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466 https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b054625 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •