Vulnerabilidades

*** Pendiente de traducción *** A weakness has been identified in Open Asset Import Library Assimp 6.0.2. This affects the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. Executing manipulation can lead to heap-based buffer overflow. The attack needs to be launched locally. The exploit has been made available to the public and could be exploited.

*** Pendiente de traducción *** A security flaw has been discovered in Rebuild up to 4.1.3. Affected by this issue is some unknown functionality of the component Comment/Guestbook. Performing manipulation results in cross site scripting. It is possible to initiate the attack remotely. Upgrading to version 4.1.4 can resolve this issue. It is suggested to upgrade the affected component. According to the researcher the vendor has confirmed the flaw and fix in a private issue response.

*** Pendiente de traducción *** A vulnerability was determined in Open Asset Import Library Assimp 6.0.2. Affected is the function Q3DImporter::InternReadFile of the file assimp/code/AssetLib/Q3D/Q3DLoader.cpp. This manipulation causes allocation of resources. The attack is restricted to local execution. The exploit has been publicly disclosed and may be utilized.

*** Pendiente de traducción *** A vulnerability was identified in Open Asset Import Library Assimp 6.0.2. Affected by this vulnerability is the function ODDLParser::getNextSeparator in the library assimp/contrib/openddlparser/include/openddlparser/OpenDDLParserUtils.h. Such manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit is publicly available and might be used.

*** Pendiente de traducción *** A vulnerability was found in LaChatterie Verger up to 1.2.10. This impacts the function redirectToAuthorization of the file /src/main/services/mcp/oauth/provider.ts. The manipulation of the argument URL results in deserialization. The attack can be executed remotely. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** A vulnerability has been found in SeriaWei ZKEACMS up to 4.3. This affects the function Delete of the file src/ZKEACMS.Redirection/Controllers/UrlRedirectionController.cs of the component POST Request Handler. The manipulation leads to improper authorization. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix invalid free of JFS_IP(ipimap)-&gt;i_imap in diUnmount<br /> <br /> syzbot found an invalid-free in diUnmount:<br /> <br /> BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]<br /> BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674<br /> Free of addr ffff88806f410000 by task syz-executor131/3632<br /> <br /> CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106<br /> print_address_description+0x74/0x340 mm/kasan/report.c:284<br /> print_report+0x107/0x1f0 mm/kasan/report.c:395<br /> kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460<br /> ____kasan_slab_free+0xfb/0x120<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1724 [inline]<br /> slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750<br /> slab_free mm/slub.c:3661 [inline]<br /> __kmem_cache_free+0x71/0x110 mm/slub.c:3674<br /> diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195<br /> jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63<br /> jfs_put_super+0x86/0x190 fs/jfs/super.c:194<br /> generic_shutdown_super+0x130/0x310 fs/super.c:492<br /> kill_block_super+0x79/0xd0 fs/super.c:1428<br /> deactivate_locked_super+0xa7/0xf0 fs/super.c:332<br /> cleanup_mnt+0x494/0x520 fs/namespace.c:1186<br /> task_work_run+0x243/0x300 kernel/task_work.c:179<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0x664/0x2070 kernel/exit.c:820<br /> do_group_exit+0x1fd/0x2b0 kernel/exit.c:950<br /> __do_sys_exit_group kernel/exit.c:961 [inline]<br /> __se_sys_exit_group kernel/exit.c:959 [inline]<br /> __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> JFS_IP(ipimap)-&gt;i_imap is not setting to NULL after free in diUnmount.<br /> If jfs_remount() free JFS_IP(ipimap)-&gt;i_imap but then failed at diMount().<br /> JFS_IP(ipimap)-&gt;i_imap will be freed once again.<br /> Fix this problem by setting JFS_IP(ipimap)-&gt;i_imap to NULL after free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix deletion race condition<br /> <br /> System crash when using debug kernel due to link list corruption. The cause<br /> of the link list corruption is due to session deletion was allowed to queue<br /> up twice. Here&amp;#39;s the internal trace that show the same port was allowed to<br /> double queue for deletion on different cpu.<br /> <br /> 20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1<br /> 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1<br /> <br /> Move the clearing/setting of deleted flag lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/ksm: fix race with VMA iteration and mm_struct teardown<br /> <br /> exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held<br /> in write mode. Ensure that the maple tree is still valid by checking<br /> ksm_test_exit() after taking the mmap_lock in read mode, but before the<br /> for_each_vma() iterator dereferences a destroyed maple tree.<br /> <br /> Since the maple tree is destroyed, the flags telling lockdep to check an<br /> external lock has been cleared. Skip the for_each_vma() iterator to avoid<br /> dereferencing a maple tree without the external lock flag, which would<br /> create a lockdep warning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dax: Fix dax_mapping_release() use after free<br /> <br /> A CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region<br /> provider (like modprobe -r dax_hmem) yields:<br /> <br /> kobject: &amp;#39;mapping0&amp;#39; (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000)<br /> [..]<br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260<br /> [..]<br /> RIP: 0010:__lock_acquire+0x9fc/0x2260<br /> [..]<br /> Call Trace:<br /> <br /> [..]<br /> lock_acquire+0xd4/0x2c0<br /> ? ida_free+0x62/0x130<br /> _raw_spin_lock_irqsave+0x47/0x70<br /> ? ida_free+0x62/0x130<br /> ida_free+0x62/0x130<br /> dax_mapping_release+0x1f/0x30<br /> device_release+0x36/0x90<br /> kobject_delayed_cleanup+0x46/0x150<br /> <br /> Due to attempting ida_free() on an ida object that has already been<br /> freed. Devices typically only hold a reference on their parent while<br /> registered. If a child needs a parent object to complete its release it<br /> needs to hold a reference that it drops from its release callback.<br /> Arrange for a dax_mapping to pin its parent dev_dax instance until<br /> dax_mapping_release().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (coretemp) Simplify platform device handling<br /> <br /> Coretemp&amp;#39;s platform driver is unconventional. All the real work is done<br /> globally by the initcall and CPU hotplug notifiers, while the "driver"<br /> effectively just wraps an allocation and the registration of the hwmon<br /> interface in a long-winded round-trip through the driver core. The whole<br /> logic of dynamically creating and destroying platform devices to bring<br /> the interfaces up and down is error prone, since it assumes<br /> platform_device_add() will synchronously bind the driver and set drvdata<br /> before it returns, thus results in a NULL dereference if drivers_autoprobe<br /> is turned off for the platform bus. Furthermore, the unusual approach of<br /> doing that from within a CPU hotplug notifier, already commented in the<br /> code that it deadlocks suspend, also causes lockdep issues for other<br /> drivers or subsystems which may want to legitimately register a CPU<br /> hotplug notifier from a platform bus notifier.<br /> <br /> All of these issues can be solved by ripping this unusual behaviour out<br /> completely, simply tying the platform devices to the lifetime of the<br /> module itself, and directly managing the hwmon interfaces from the<br /> hotplug notifiers. There is a slight user-visible change in that<br /> /sys/bus/platform/drivers/coretemp will no longer appear, and<br /> /sys/devices/platform/coretemp.n will remain present if package n is<br /> hotplugged off, but hwmon users should really only be looking for the<br /> presence of the hwmon interfaces, whose behaviour remains unchanged.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi_si: fix a memleak in try_smi_init()<br /> <br /> Kmemleak reported the following leak info in try_smi_init():<br /> <br /> unreferenced object 0xffff00018ecf9400 (size 1024):<br /> comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)<br /> backtrace:<br /> [] __kmalloc+0x4b8/0x7b0<br /> [] try_smi_init+0x148/0x5dc [ipmi_si]<br /> [] 0xffff800081b10148<br /> [] do_one_initcall+0x64/0x2a4<br /> [] do_init_module+0x50/0x300<br /> [] load_module+0x7a8/0x9e0<br /> [] __se_sys_init_module+0x104/0x180<br /> [] __arm64_sys_init_module+0x24/0x30<br /> [] el0_svc_common.constprop.0+0x94/0x250<br /> [] do_el0_svc+0x48/0xe0<br /> [] el0_svc+0x24/0x3c<br /> [] el0_sync_handler+0x160/0x164<br /> [] el0_sync+0x160/0x180<br /> <br /> The problem was that when an error occurred before handlers registration<br /> and after allocating `new_smi-&gt;si_sm`, the variable wouldn&amp;#39;t be freed in<br /> the error handling afterwards since `shutdown_smi()` hadn&amp;#39;t been<br /> registered yet. Fix it by adding a `kfree()` in the error handling path<br /> in `try_smi_init()`.