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 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39487 – bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
https://notcve.org/view.php?id=CVE-2024-39487
In the Linux kernel, the following vulnerability has been resolved: bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: corrige la lectura fuera de los límites en bond_option_arp_ip_targets_set() En la función bond_option_arp_ip_targets_set(), si newval->string es una cadena vacía, newval->string+1 apuntará a el byte después de la cadena, lo que provoca una lectura fuera de los límites. ERROR: KASAN: slab-out-of-bounds en strlen+0x7d/0xa0 lib/string.c:418 Lectura del tamaño 1 en la dirección ffff8881119c4781 por tarea syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 No tainted 6.7.0-rc7 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [en línea] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report. c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [en línea] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 controladores /net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 controladores/net/bonding/bond_options.c: 767 __bond_opt_set_notify+0x48/0x150 Drivers/net/bonding/bond_options.c: 792 bond_pt_tryset neto /bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c :136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x96a/0xd80 fs/read_write.c :584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6 ---[rastreo final]--- Solucionelo agregando una verificación de la longitud de la cadena antes de usarlo. • https://git.kernel.org/stable/c/f9de11a165943a55e0fbda714caf60eaeb276a42 https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1 https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9 https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8 https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7a •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39484 – mmc: davinci: Don't strip remove function when driver is builtin
https://notcve.org/view.php?id=CVE-2024-39484
In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: davinci: no eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_MMC_DAVINCI=y. • https://git.kernel.org/stable/c/b4cff4549b7a8c5fc8b88e3493b6287555f0512c https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4 https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1 https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584 https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39482 – bcache: fix variable length array abuse in btree_iter
https://notcve.org/view.php?id=CVE-2024-39482
In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: corrige el abuso de matriz de longitud variable en btree_iter btree_iter se usa de dos maneras: ya sea asignado en la pila con un tamaño fijo MAX_BSETS, o desde un mempool con un tamaño dinámico basado en el conjunto de caché específico. Anteriormente, la estructura tenía una matriz de longitud fija de tamaño MAX_BSETS que estaba indexada fuera de los límites para los iteradores de tamaño dinámico, lo que provoca que UBSAN se queje. Este parche utiliza el mismo enfoque que en sort_iter de bcachefs y divide el iterador en un btree_iter con un miembro de matriz flexible y un btree_iter_stack que incorpora un btree_iter así como una matriz de datos de longitud fija. • https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023 https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02 https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148 https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671 https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31 • CWE-770: Allocation of Resources Without Limits or Throttling •