CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26593 – i2c: i801: Fix block process call transactions
https://notcve.org/view.php?id=CVE-2024-26593
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: i801: Reparar transacciones de llamada de proceso de bloque Según las hojas de datos de Intel, el software debe restablecer el índice del búfer de bloque dos veces para transacciones de llamada de proceso de bloque: una vez antes de escribir los datos salientes en el búfer , y una vez más antes de leer los datos entrantes del búfer. Actualmente, al controlador le falta el segundo reinicio, lo que provoca que se lea la parte incorrecta del búfer de bloque. • https://git.kernel.org/stable/c/315cd67c945351f8a569500f8ab16b7fa94026e8 https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7 https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9 https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2 https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e1662428 • CWE-125: Out-of-bounds Read •
CVSS: 9.3EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26594 – ksmbd: validate mech token in session setup
https://notcve.org/view.php?id=CVE-2024-26594
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it is invalid. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ksmbd: validar el token mecánico en la configuración de la sesión Si el cliente envía un token mecánico no válido en la solicitud de configuración de la sesión, ksmbd valida y genera el error si no es válido. This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication is not required to exploit this vulnerability. However, only systems with ksmbd enabled are vulnerable. The specific flaw exists within the handling of SMB2 Mech Tokens. • https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9 https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d • CWE-125: Out-of-bounds Read •
CVSS: 9.0EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26592 – ksmbd: fix UAF issue in ksmbd_tcp_new_connection()
https://notcve.org/view.php?id=CVE-2024-26592
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: 0CVE-2024-26591 – bpf: Fix re-attachment branch in bpf_tracing_prog_attach
https://notcve.org/view.php?id=CVE-2024-26591
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 • CWE-476: NULL Pointer Dereference •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52452 – bpf: Fix accesses to uninit stack slots
https://notcve.org/view.php?id=CVE-2023-52452
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 •