Page 147 of 2802 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs:zoned: corrige el use-after-free debido a la ejecución con el reemplazo de desarrollo. Mientras cargamos la información de una zona durante la creación de un grupo de bloques, podemos ejecutar una operación de reemplazo de dispositivo y luego activar un use-after-free en el dispositivo que acaba de ser reemplazado (dispositivo fuente de la operación de reemplazo). Esto sucede porque en btrfs_load_zone_info() extraemos un dispositivo del mapa de fragmentos en una variable local y luego usamos el dispositivo mientras no está bajo la protección del dispositivo y reemplazamos rwsem. • https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43 https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6 https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752 https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: greybus: Fix use-after-free bug in gb_interface_release due to race condition. In gb_interface_create, &intf->mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". • https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201 https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83 https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9 https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445 https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce • CWE-416: Use After Free •

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

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: 5.5EPSS: 0%CPEs: 8EXPL: 0

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: 0

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-&gt;string es una cadena vacía, newval-&gt;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 •