Page 190 of 2293 results (0.012 seconds)

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix possible use-after-free issue in ftrace_location() KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. • https://git.kernel.org/stable/c/ae6aa16fdc163afe6b04b6c073ad4ddd4663c03b https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831 https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461 https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6 https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: speakup: Fix sizeof() vs ARRAY_SIZE() bug The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Speakup: corrige el error sizeof() vs ARRAY_SIZE() El puntero "buf" es una matriz de valores u16. Este código debería usar ARRAY_SIZE() (que es 256) en lugar de sizeof() (que es 512), de lo contrario aún puede salirse de los límites. • https://git.kernel.org/stable/c/756c5cb7c09e537b87b5d3acafcb101b2ccf394f https://git.kernel.org/stable/c/8f6b62125befe1675446923e4171eac2c012959c https://git.kernel.org/stable/c/6401038acfa24cba9c28cce410b7505efadd0222 https://git.kernel.org/stable/c/0d130158db29f5e0b3893154908cf618896450a8 https://git.kernel.org/stable/c/89af25bd4b4bf6a71295f07e07a8ae7dc03c6595 https://git.kernel.org/stable/c/8defb1d22ba0395b81feb963b96e252b097ba76f https://git.kernel.org/stable/c/0efb15c14c493263cb3a5f65f5ddfd4603d19a76 https://git.kernel.org/stable/c/c8d2f34ea96ea3bce6ba2535f867f0d4e •

CVSS: 4.1EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: corrige una posible corrupción del búfer en anillo en paquetes Tx fragmentados. Se encontró un problema en el RTL8125b al transmitir pequeños paquetes fragmentados, por el cual se insertaban entradas no válidas en el búfer del anillo de transmisión, lo que posteriormente generaba llamadas a dma_unmap_single() con una dirección nula. Esto se debió a que rtl8169_start_xmit() no notó los cambios en nr_frags que pueden ocurrir cuando se rellenan paquetes pequeños (para evitar peculiaridades del hardware) en rtl8169_tso_csum_v2(). Para solucionar este problema, posponga la inspección de nr_frags hasta que se haya aplicado el relleno. • https://git.kernel.org/stable/c/9020845fb5d6bb4876a38fdf1259600e7d9a63d4 https://git.kernel.org/stable/c/61c1c98e2607120ce9c3fa1bf75e6da909712b27 https://git.kernel.org/stable/c/b6d21cf40de103d63ae78551098a7c06af8c98dd https://git.kernel.org/stable/c/0c48185a95309556725f818b82120bb74e9c627d https://git.kernel.org/stable/c/68222d7b4b72aa321135cd453dac37f00ec41fd1 https://git.kernel.org/stable/c/078d5b7500d70af2de6b38e226b03f0b932026a6 https://git.kernel.org/stable/c/54e7a0d111240c92c0f02ceba6eb8f26bf6d6479 https://git.kernel.org/stable/c/c71e3a5cffd5309d7f84444df03d5b726 • CWE-457: Use of Uninitialized Variable •

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

In the Linux kernel, the following vulnerability has been resolved: tools/nolibc/stdlib: fix memory error in realloc() Pass user_p_len to memcpy() instead of heap->len to prevent realloc() from copying an extra sizeof(heap) bytes from beyond the allocated region. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tools/nolibc/stdlib: corrige el error de memoria en realloc() Pase user_p_len a memcpy() en lugar de heap-&gt;len para evitar que realloc() copie un tamaño extra de(heap) bytes más allá de la región asignada. • https://git.kernel.org/stable/c/0e0ff638400be8f497a35b51a4751fd823f6bd6a https://git.kernel.org/stable/c/5996b2b2dac739f2a27da13de8eee5b85b2550b3 https://git.kernel.org/stable/c/f678c3c336559cf3255a32153e9a17c1be4e7c15 https://git.kernel.org/stable/c/8019d3dd921f39a237a9fab6d2ce716bfac0f983 https://git.kernel.org/stable/c/4e6f225aefeb712cdb870176b6621f02cf235b8c https://git.kernel.org/stable/c/791f4641142e2aced85de082e5783b4fb0b977c2 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe() In the prueth_probe() function, if one of the calls to emac_phy_connect() fails due to of_phy_connect() returning NULL, then the subsequent call to phy_attached_info() will dereference a NULL pointer. Check the return code of emac_phy_connect and fail cleanly if there is an error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ti: icssg_prueth: corrige la desreferencia del puntero NULL en prueth_probe() En la función prueth_probe(), si una de las llamadas a emac_phy_connect() falla debido a que of_phy_connect() devuelve NULL , entonces la llamada posterior a phy_attached_info() eliminará la referencia a un puntero NULL. Verifique el código de retorno de emac_phy_connect y falle limpiamente si hay un error. • https://git.kernel.org/stable/c/128d5874c0822105ae9556d5435fb8562aff2e3b https://git.kernel.org/stable/c/5cd17f0e74cb99d209945b9f1f06d411aa667eb1 https://git.kernel.org/stable/c/b0a82ebabbdc4c307f781bb0e5cd617949a3900d https://git.kernel.org/stable/c/1e1d5bd7f4682e6925dd960aba2a1aa1d93da53a https://git.kernel.org/stable/c/b31c7e78086127a7fcaa761e8d336ee855a920c6 •