Page 703 of 4415 results (0.019 seconds)

CVSS: 9.0EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF issue in ksmbd_tcp_new_connection() The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on `struct tcp_transport` in ksmbd_tcp_new_connection() function. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ksmbd: soluciona problema de UAF en ksmbd_tcp_new_connection() La ejecución es entre el manejo de una nueva conexión TCP y su desconexión. Conduce a UAF en `struct tcp_transport` en la función ksmbd_tcp_new_connection(). This vulnerability allows remote attackers to execute arbitrary code on affected installations of Linux Kernel. • https://git.kernel.org/stable/c/a848c4f15ab6d5d405dbee7de5da71839b2bf35e https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6 https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1 https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111 https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126 https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544 • CWE-416: Use After Free •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? • https://git.kernel.org/stable/c/f3a95075549e0e5c36db922caf86847db7a35403 https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653 https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0 https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee https://access.redhat.com/security/cve/CVE-2024-26591 https://bugzilla.redhat.com/show_bug.cgi?id=2265648 • CWE-476: NULL Pointer Dereference •

CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. • https://git.kernel.org/stable/c/01f810ace9ed37255f27608a0864abebccf0aab3 https://git.kernel.org/stable/c/f3c4b01689d392373301e6e60d1b02c5b4020afc https://git.kernel.org/stable/c/d1b725ea5d104caea250427899f4e2e3ab15b4fc https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19 https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529 • CWE-665: Improper Initialization •

CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries/memhp: corrige el acceso más allá del final de la matriz drmem dlpar_memory_remove_by_index() puede acceder más allá de los límites de la matriz lmb drmem cuando la búsqueda de LMB no coincide con una entrada con el valor dado Índice de la República Democrática del Congo. Cuando la búsqueda falla, el cursor queda apuntando a &amp;drmem_info-&gt;lmbs[drmem_info-&gt;n_lmbs], que es un elemento después de la última entrada válida en la matriz. • https://git.kernel.org/stable/c/51925fb3c5c901aa06cdc853268a6e19e19bcdc7 https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7 https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0 https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3a • CWE-125: Out-of-bounds Read CWE-129: Improper Validation of Array Index •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/uncore: Fix NULL pointer dereference issue in upi_fill_topology() Get logical socket id instead of physical id in discover_upi_topology() to avoid out-of-bound access on 'upi = &type->topology[nid][idx];' line that leads to NULL pointer dereference in upi_fill_topology() En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/x86/intel/uncore: solucione el problema de desreferencia del puntero NULL en upi_fill_topology(). Obtenga la identificación del socket lógico en lugar de la identificación física en discover_upi_topology() para evitar el acceso fuera de límites en 'upi = &amp;tipo-&gt;topología[nid][idx];' línea que conduce a la desreferencia del puntero NULL en upi_fill_topology() A vulnerability was discovered in the Linux kernel in which certain CPU topologies could result in a null pointer dereference, affecting system stability. • https://git.kernel.org/stable/c/f680b6e6062ef3c944ffc966d685f067958fca33 https://git.kernel.org/stable/c/bf1bf09e6b599758851457f3999779622a48d015 https://git.kernel.org/stable/c/3d6f4a78b104c65e4256c3776c9949f49a1b459e https://git.kernel.org/stable/c/1692cf434ba13ee212495b5af795b6a07e986ce4 https://access.redhat.com/security/cve/CVE-2023-52450 https://bugzilla.redhat.com/show_bug.cgi?id=2265649 • CWE-476: NULL Pointer Dereference •