CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-39494 – ima: Fix use-after-free on a dentry's dname.name
https://notcve.org/view.php?id=CVE-2024-39494
In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ima: corrige el use-after-free en dentry dname.name ->d_name.name puede cambiar al cambiar el nombre y el valor anterior se puede liberar; existen condiciones suficientes para estabilizarlo (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusivo en el inodo del padre, rename_lock), pero ninguna de ellas se cumple en ninguno de los sitios. En su lugar, tome una instantánea estable del nombre. • https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4 https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 10EXPL: 0CVE-2024-39493 – crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak
https://notcve.org/view.php?id=CVE-2024-39493
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak Using completion_done to determine whether the caller has gone away only works after a complete call. Furthermore it's still possible that the caller has not yet called wait_for_completion, resulting in another potential UAF. Fix this by making the caller use cancel_work_sync and then freeing the memory safely. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: qat: corrige la pérdida de memoria ADF_DEV_RESET_SYNC. El uso de complete_done para determinar si la persona que llama se ha ido solo funciona después de una llamada completa. Además, aún es posible que la persona que llama aún no haya llamado a wait_for_completion, lo que genera otra posible UAF. • https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7 https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81 https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71 https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7 https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-39490 – ipv6: sr: fix missing sk_buff release in seg6_input_core
https://notcve.org/view.php?id=CVE-2024-39490
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix missing sk_buff release in seg6_input_core The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6: sr: corrige la versión faltante de sk_buff en seg6_input_core La función seg6_input() es responsable de agregar el SRH a un paquete, delegando la operación al seg6_input_core(). Esta función utiliza skb_cow_head() para garantizar que haya suficiente espacio libre en sk_buff para acomodar el encabezado de la capa de enlace. En caso de que la función skb_cow_header() falle, seg6_input_core() detecta el error pero no libera sk_buff, lo que provocará una pérdida de memoria. • https://git.kernel.org/stable/c/af3b5158b89d3bab9be881113417558c71b71ca4 https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864 https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8 https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940 https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39489 – ipv6: sr: fix memleak in seg6_hmac_init_algo
https://notcve.org/view.php?id=CVE-2024-39489
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix memleak in seg6_hmac_init_algo seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: sr: corrige memleak en seg6_hmac_init_algo seg6_hmac_init_algo regresa sin limpiar las asignaciones anteriores si una falla, por lo que perderá toda esa memoria y los tfms criptográficos. Actualice seg6_hmac_exit para liberar solo la memoria cuando esté asignada, de modo que podamos reutilizar el código directamente. • https://git.kernel.org/stable/c/bf355b8d2c30a289232042cacc1cfaea4923936c https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976 https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3 https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821 https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6 https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39488 – arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
https://notcve.org/view.php?id=CVE-2024-39488
In the Linux kernel, the following vulnerability has been resolved: arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: arm64: asm-bug: agregue .align 2 al final de __BUG_ENTRY Cuando CONFIG_DEBUG_BUGVERBOSE=n, no agregamos los bytes de relleno necesarios a las entradas de bug_table y, como resultado, la última entrada en una tabla de errores se ignorará, lo que podría provocar un pánico inesperado(). Todas las entradas anteriores en la tabla se manejarán correctamente. La ABI arm64 requiere que los campos de estructura de hasta 8 bytes estén alineados de forma natural, con relleno agregado dentro de una estructura de modo que la estructura esté adecuadamente alineada dentro de las matrices. Cuando CONFIG_DEBUG_BUGVERPOSE=y, el diseño de una entrada de error es: struct bug_entry { firmado int bug_addr_disp; // 4 bytes firmados int file_disp; // Línea corta sin firmar de 4 bytes; // 2 bytes de banderas cortas sin firmar; // 2 bytes } ... con 12 bytes en total, que requieren una alineación de 4 bytes. • https://git.kernel.org/stable/c/9fb7410f955f7a62c1f882ca8f9ffd4525907e28 https://git.kernel.org/stable/c/f221bd58db0f6ca087ac0392284f6bce21f4f8ea https://git.kernel.org/stable/c/22469a0335a1a1a690349b58bcb55822457df81e https://git.kernel.org/stable/c/461a760d578b2b2c2faac3040b6b7c77baf128f8 https://git.kernel.org/stable/c/c1929c041a262a4a27265db8dce3619c92aa678c https://git.kernel.org/stable/c/3fd487ffaa697ddb05af78a75aaaddabe71c52b0 https://git.kernel.org/stable/c/9f2ad88f9b349554f64e4037ec185c84d7dd9c7d https://git.kernel.org/stable/c/c27a2f7668e215c1ebbccd96fab27a220 •