Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, Fix memory leak in hws_pool_buddy_init error path<br /> <br /> In the error path of hws_pool_buddy_init(), the buddy allocator cleanup<br /> doesn&amp;#39;t free the allocator structure itself, causing a memory leak.<br /> <br /> Add the missing kfree() to properly release all allocated memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbnic: Move phylink resume out of service_task and into open/close<br /> <br /> The fbnic driver was presenting with the following locking assert coming<br /> out of a PM resume:<br /> [ 42.208116][ T164] RTNL: assertion failed at drivers/net/phy/phylink.c (2611)<br /> [ 42.208492][ T164] WARNING: CPU: 1 PID: 164 at drivers/net/phy/phylink.c:2611 phylink_resume+0x190/0x1e0<br /> [ 42.208872][ T164] Modules linked in:<br /> [ 42.209140][ T164] CPU: 1 UID: 0 PID: 164 Comm: bash Not tainted 6.17.0-rc2-virtme #134 PREEMPT(full)<br /> [ 42.209496][ T164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014<br /> [ 42.209861][ T164] RIP: 0010:phylink_resume+0x190/0x1e0<br /> [ 42.210057][ T164] Code: 83 e5 01 0f 85 b0 fe ff ff c6 05 1c cd 3e 02 01 90 ba 33 0a 00 00 48 c7 c6 20 3a 1d a5 48 c7 c7 e0 3e 1d a5 e8 21 b8 90 fe 90 0b 90 90 e9 86 fe ff ff e8 42 ea 1f ff e9 e2 fe ff ff 48 89 ef<br /> [ 42.210708][ T164] RSP: 0018:ffffc90000affbd8 EFLAGS: 00010296<br /> [ 42.210983][ T164] RAX: 0000000000000000 RBX: ffff8880078d8400 RCX: 0000000000000000<br /> [ 42.211235][ T164] RDX: 0000000000000000 RSI: 1ffffffff4f10938 RDI: 0000000000000001<br /> [ 42.211466][ T164] RBP: 0000000000000000 R08: ffffffffa2ae79ea R09: fffffbfff4b3eb84<br /> [ 42.211707][ T164] R10: 0000000000000003 R11: 0000000000000000 R12: ffff888007ad8000<br /> [ 42.211997][ T164] R13: 0000000000000002 R14: ffff888006a18800 R15: ffffffffa34c59e0<br /> [ 42.212234][ T164] FS: 00007f0dc8e39740(0000) GS:ffff88808f51f000(0000) knlGS:0000000000000000<br /> [ 42.212505][ T164] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0<br /> [ 42.213227][ T164] PKRU: 55555554<br /> [ 42.213366][ T164] Call Trace:<br /> [ 42.213483][ T164] <br /> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0<br /> [ 42.213725][ T164] pci_reset_function+0x116/0x1d0<br /> [ 42.213895][ T164] reset_store+0xa0/0x100<br /> [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50<br /> [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0<br /> [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160<br /> [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0<br /> [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0<br /> [ 42.214836][ T164] new_sync_write+0x308/0x6f0<br /> [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740<br /> [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0<br /> [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260<br /> [ 42.215440][ T164] ? ksys_write+0xff/0x200<br /> [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0<br /> [ 42.215742][ T164] vfs_write+0x65e/0xbb0<br /> [ 42.215876][ T164] ksys_write+0xff/0x200<br /> [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0<br /> [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0<br /> [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0<br /> [ 42.216442][ T164] do_syscall_64+0xbb/0x360<br /> [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986<br /> <br /> A bit of digging showed that we were invoking the phylink_resume as a part<br /> of the fbnic_up path when we were enabling the service task while not<br /> holding the RTNL lock. We should be enabling this sooner as a part of the<br /> ndo_open path and then just letting the service task come online later.<br /> This will help to enforce the correct locking and brings the phylink<br /> interface online at the same time as the network interface, instead of at a<br /> later time.<br /> <br /> I tested this on QEMU to verify this was working by putting the system to<br /> sleep using "echo mem &gt; /sys/power/state" to put the system to sleep in the<br /> guest and then using the command "system_wakeup" in the QEMU monitor.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix lockdep assertion on sync reset unload event<br /> <br /> Fix lockdep assertion triggered during sync reset unload event. When the<br /> sync reset flow is initiated using the devlink reload fw_activate<br /> option, the PF already holds the devlink lock while handling unload<br /> event. In this case, delegate sync reset unload event handling back to<br /> the devlink callback process to avoid double-locking and resolve the<br /> lockdep warning.<br /> <br /> Kernel log:<br /> WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40<br /> [...]<br /> Call Trace:<br /> <br /> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core]<br /> mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core]<br /> process_one_work+0x222/0x640<br /> worker_thread+0x199/0x350<br /> kthread+0x10b/0x230<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x8e/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: hfcpci: Fix warning when deleting uninitialized timer<br /> <br /> With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads<br /> to the following splat:<br /> <br /> [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0<br /> [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0<br /> [ 250.218775] Modules linked in: hfcpci(-) mISDN_core<br /> [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)<br /> [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0<br /> [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d<br /> [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286<br /> [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95<br /> [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0<br /> [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39<br /> [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001<br /> [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8<br /> [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000<br /> [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0<br /> [ 250.236117] Call Trace:<br /> [ 250.236599] <br /> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130<br /> [ 250.237920] debug_object_assert_init+0x1f6/0x310<br /> [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10<br /> [ 250.239658] ? __lock_acquire+0xdea/0x1c70<br /> [ 250.240369] __try_to_del_timer_sync+0x69/0x140<br /> [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10<br /> [ 250.242058] ? __timer_delete_sync+0xc6/0x120<br /> [ 250.242842] ? lock_acquire+0x30/0x80<br /> [ 250.243474] ? __timer_delete_sync+0xc6/0x120<br /> [ 250.244262] __timer_delete_sync+0x98/0x120<br /> [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci]<br /> [ 250.245704] __do_sys_delete_module+0x348/0x510<br /> [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10<br /> [ 250.247338] do_syscall_64+0xc1/0x360<br /> [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Fix this by initializing hfc_tl timer with DEFINE_TIMER macro.<br /> Also, use mod_timer instead of manual timeout update.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow<br /> <br /> When an invalid stc_type is provided, the function allocates memory for<br /> shared_stc but jumps to unlock_and_out without freeing it, causing a<br /> memory leak.<br /> <br /> Fix by jumping to free_shared_stc label instead to ensure proper cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: do not propagate ENODATA disk errors into xattr code<br /> <br /> ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;<br /> namely, that the requested attribute name could not be found.<br /> <br /> However, a medium error from disk may also return ENODATA. At best,<br /> this medium error may escape to userspace as "attribute not found"<br /> when in fact it&amp;#39;s an IO (disk) error.<br /> <br /> At worst, we may oops in xfs_attr_leaf_get() when we do:<br /> <br /> error = xfs_attr_leaf_hasname(args, &amp;bp);<br /> if (error == -ENOATTR) {<br /> xfs_trans_brelse(args-&gt;trans, bp);<br /> return error;<br /> }<br /> <br /> because an ENODATA/ENOATTR error from disk leaves us with a null bp,<br /> and the xfs_trans_brelse will then null-deref it.<br /> <br /> As discussed on the list, we really need to modify the lower level<br /> IO functions to trap all disk errors and ensure that we don&amp;#39;t let<br /> unique errors like this leak up into higher xfs functions - many<br /> like this should be remapped to EIO.<br /> <br /> However, this patch directly addresses a reported bug in the xattr<br /> code, and should be safe to backport to stable kernels. A larger-scope<br /> patch to handle more unique errors at lower levels can follow later.<br /> <br /> (Note, prior to 07120f1abdff we did not oops, but we did return the<br /> wrong error code to userspace.)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: stmm: Fix incorrect buffer allocation method<br /> <br /> The communication buffer allocated by setup_mm_hdr() is later on passed<br /> to tee_shm_register_kernel_buf(). The latter expects those buffers to be<br /> contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause<br /> various corruptions or BUGs, specifically since commit 9aec2fb0fd5e<br /> ("slab: allocate frozen pages"), though it was broken before as well.<br /> <br /> Fix this by using alloc_pages_exact() instead of kmalloc().

*** Pendiente de traducción *** Improper Neutralization of Input During Web Page Generation (XSS or &amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Holistic IT, Consultancy Coop. Workcube ERP allows Reflected XSS.This issue affects Workcube ERP: from V12 - V14 through 20250916. <br /> <br /> NOTE: The vendor did not inform about the completion of the fixing process within the specified time. The CVE will be updated when new information becomes available.

*** Pendiente de traducción *** Authorization Bypass Through User-Controlled Key vulnerability in Beefull Energy Technologies Beefull App allows Exploitation of Trusted Identifiers.This issue affects Beefull App: before 24.07.2025.

*** Pendiente de traducción *** Memory corruptions can be remotely triggered in the Control-M/Agent when SSL/TLS communication is configured.<br /> <br /> <br /> The issue occurs in the following cases:<br /> <br /> * Control-M/Agent 9.0.20: SSL/TLS configuration is set to the non-default setting "use_openssl=n";<br /> * Control-M/Agent 9.0.21 and 9.0.22: Agent router configuration uses the non-default settings "JAVA_AR=N" and "use_openssl=n".

*** Pendiente de traducción *** A Cross Site Scripting vulnerability in JeeWMS v.3.7 and before allows a remote attacker to obtain sensitive information via the logController.do component

*** Pendiente de traducción *** A stack-based buffer overflow can be remotely triggered when formatting an error message in the Control-M/Agent when SSL/TLS communication is configured.<br /> <br /> <br /> The issue occurs in the following cases:<br /> <br /> * Control-M/Agent 9.0.20: SSL/TLS configuration is set to the non-default setting "use_openssl=n";<br /> * Control-M/Agent 9.0.21 and 9.0.22: Agent router configuration uses the non-default settings "JAVA_AR=N" and "use_openssl=n".