Vulnerabilidades

*** Pendiente de traducción *** The improper order of AUTHORIZED_CTM_IP validation in the Control-M/Agent, where the Control-M/Server IP address is validated only after the SSL/TLS handshake is completed, exposes the Control-M/Agent to vulnerabilities in the SSL/TLS implementation under certain non-default conditions (e.g. CVE-2025-55117 or CVE-2025-55118) or potentially to resource exhaustion.

*** Pendiente de traducción *** Out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 (and potentially earlier unsupported versions) that are configured to use the non-default Blowfish cryptography algorithm use a hardcoded key. An attacker with access to network traffic and to this key could decrypt network traffic between the Control-M/Agent and Server.

*** Pendiente de traducción *** Certain files with overly permissive permissions were identified in the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions as well as in newer versions which were upgraded from an affected version. These files contain keys and passwords relating to SSL files, keystore and policies. An attacker with local access to the system running the Agent can access these files.

*** Pendiente de traducción *** An authentication bypass vulnerability exists in the out-of-support Control-M/Agent versions 9.0.18 to 9.0.20 and potentially earlier unsupported versions when using an empty or default kdb keystore or a default PKCS#12 keystore. A remote attacker with access to a signed third-party or demo certificate for client authentication can bypass the need for a certificate signed by the certificate authority of the organization during authentication on the Control-M/Agent.<br /> <br /> The Control-M/Agent contains hardcoded certificates which are only trusted as fallback if an empty kdb keystore is used; they are never trusted if a PKCS#12 keystore is used. All of these certificates are now expired.<br /> <br /> <br /> In addition, the Control-M/Agent default kdb and PKCS#12 keystores contain trusted third-party certificates (external recognized CAs and default self-signed demo certificates) which are trusted for client authentication.

*** Pendiente de traducción *** Control-M/Agents use a kdb or PKCS#12 keystore by default, and the default keystore password is well known and documented.<br /> <br /> An attacker with read access to the keystore could access sensitive data using this password.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> When atmtcp_v_open() or atmtcp_v_close() is called via connect()<br /> or close(), atmtcp_send_control() is called to send an in-kernel<br /> special message.<br /> <br /> The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.<br /> Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.<br /> <br /> The notable thing is struct atmtcp_control is uAPI but has a<br /> space for an in-kernel pointer.<br /> <br /> struct atmtcp_control {<br /> struct atmtcp_hdr hdr; /* must be first */<br /> ...<br /> atm_kptr_t vcc; /* both directions */<br /> ...<br /> } __ATM_API_ALIGN;<br /> <br /> typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;<br /> <br /> The special message is processed in atmtcp_recv_control() called<br /> from atmtcp_c_send().<br /> <br /> atmtcp_c_send() is vcc-&gt;dev-&gt;ops-&gt;send() and called from 2 paths:<br /> <br /> 1. .ndo_start_xmit() (vcc-&gt;send() == atm_send_aal0())<br /> 2. vcc_sendmsg()<br /> <br /> The problem is sendmsg() does not validate the message length and<br /> userspace can abuse atmtcp_recv_control() to overwrite any kptr<br /> by atmtcp_control.<br /> <br /> Let&amp;#39;s add a new -&gt;pre_send() hook to validate messages from sendmsg().<br /> <br /> [0]:<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI<br /> KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]<br /> CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]<br /> RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297<br /> Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c<br /> RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203<br /> RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c<br /> RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd<br /> R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000<br /> R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff<br /> FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> __sock_sendmsg+0x219/0x270 net/socket.c:729<br /> ____sys_sendmsg+0x505/0x830 net/socket.c:2614<br /> ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668<br /> __sys_sendmsg net/socket.c:2700 [inline]<br /> __do_sys_sendmsg net/socket.c:2705 [inline]<br /> __se_sys_sendmsg net/socket.c:2703 [inline]<br /> __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f8d7e96a4a9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9<br /> RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005<br /> RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f<br /> R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac<br /> R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250<br /> <br /> Modules linked in:

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> trace/fgraph: Fix the warning caused by missing unregister notifier<br /> <br /> This warning was triggered during testing on v6.16:<br /> <br /> notifier callback ftrace_suspend_notifier_call already registered<br /> WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0<br /> ...<br /> Call Trace:<br /> <br /> blocking_notifier_chain_register+0x34/0x60<br /> register_ftrace_graph+0x330/0x410<br /> ftrace_profile_write+0x1e9/0x340<br /> vfs_write+0xf8/0x420<br /> ? filp_flush+0x8a/0xa0<br /> ? filp_close+0x1f/0x30<br /> ? do_dup2+0xaf/0x160<br /> ksys_write+0x65/0xe0<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> When writing to the function_profile_enabled interface, the notifier was<br /> not unregistered after start_graph_tracing failed, causing a warning the<br /> next time function_profile_enabled was written.<br /> <br /> Fixed by adding unregister_pm_notifier in the exception path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rose: convert &amp;#39;use&amp;#39; field to refcount_t<br /> <br /> The &amp;#39;use&amp;#39; field in struct rose_neigh is used as a reference counter but<br /> lacks atomicity. This can lead to race conditions where a rose_neigh<br /> structure is freed while still being referenced by other code paths.<br /> <br /> For example, when rose_neigh-&gt;use becomes zero during an ioctl operation<br /> via rose_rt_ioctl(), the structure may be removed while its timer is<br /> still active, potentially causing use-after-free issues.<br /> <br /> This patch changes the type of &amp;#39;use&amp;#39; from unsigned short to refcount_t and<br /> updates all code paths to use rose_neigh_hold() and rose_neigh_put() which<br /> operate reference counts atomically.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rose: include node references in rose_neigh refcount<br /> <br /> Current implementation maintains two separate reference counting<br /> mechanisms: the &amp;#39;count&amp;#39; field in struct rose_neigh tracks references from<br /> rose_node structures, while the &amp;#39;use&amp;#39; field (now refcount_t) tracks<br /> references from rose_sock.<br /> <br /> This patch merges these two reference counting systems using &amp;#39;use&amp;#39; field<br /> for proper reference management. Specifically, this patch adds incrementing<br /> and decrementing of rose_neigh-&gt;use when rose_neigh-&gt;count is incremented<br /> or decremented.<br /> <br /> This patch also modifies rose_rt_free(), rose_rt_device_down() and<br /> rose_clear_route() to properly release references to rose_neigh objects<br /> before freeing a rose_node through rose_remove_node().<br /> <br /> These changes ensure rose_neigh structures are properly freed only when<br /> all references, including those from rose_node structures, are released.<br /> As a result, this resolves a slab-use-after-free issue reported by Syzbot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: asus: fix UAF via HID_CLAIMED_INPUT validation<br /> <br /> After hid_hw_start() is called hidinput_connect() will eventually be<br /> called to set up the device with the input layer since the<br /> HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect()<br /> all input and output reports are processed and corresponding hid_inputs<br /> are allocated and configured via hidinput_configure_usages(). This<br /> process involves slot tagging report fields and configuring usages<br /> by setting relevant bits in the capability bitmaps. However it is possible<br /> that the capability bitmaps are not set at all leading to the subsequent<br /> hidinput_has_been_populated() check to fail leading to the freeing of the<br /> hid_input and the underlying input device.<br /> <br /> This becomes problematic because a malicious HID device like a<br /> ASUS ROG N-Key keyboard can trigger the above scenario via a<br /> specially crafted descriptor which then leads to a user-after-free<br /> when the name of the freed input device is written to later on after<br /> hid_hw_start(). Below, report 93 intentionally utilises the<br /> HID_UP_UNDEFINED Usage Page which is skipped during usage<br /> configuration, leading to the frees.<br /> <br /> 0x05, 0x0D, // Usage Page (Digitizer)<br /> 0x09, 0x05, // Usage (Touch Pad)<br /> 0xA1, 0x01, // Collection (Application)<br /> 0x85, 0x0D, // Report ID (13)<br /> 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)<br /> 0x09, 0xC5, // Usage (0xC5)<br /> 0x15, 0x00, // Logical Minimum (0)<br /> 0x26, 0xFF, 0x00, // Logical Maximum (255)<br /> 0x75, 0x08, // Report Size (8)<br /> 0x95, 0x04, // Report Count (4)<br /> 0xB1, 0x02, // Feature (Data,Var,Abs)<br /> 0x85, 0x5D, // Report ID (93)<br /> 0x06, 0x00, 0x00, // Usage Page (Undefined)<br /> 0x09, 0x01, // Usage (0x01)<br /> 0x15, 0x00, // Logical Minimum (0)<br /> 0x26, 0xFF, 0x00, // Logical Maximum (255)<br /> 0x75, 0x08, // Report Size (8)<br /> 0x95, 0x1B, // Report Count (27)<br /> 0x81, 0x02, // Input (Data,Var,Abs)<br /> 0xC0, // End Collection<br /> <br /> Below is the KASAN splat after triggering the UAF:<br /> <br /> [ 21.672709] ==================================================================<br /> [ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80<br /> [ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54<br /> [ 21.673700]<br /> [ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary)<br /> [ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> [ 21.673700] Call Trace:<br /> [ 21.673700] <br /> [ 21.673700] dump_stack_lvl+0x5f/0x80<br /> [ 21.673700] print_report+0xd1/0x660<br /> [ 21.673700] kasan_report+0xe5/0x120<br /> [ 21.673700] __asan_report_store8_noabort+0x1b/0x30<br /> [ 21.673700] asus_probe+0xeeb/0xf80<br /> [ 21.673700] hid_device_probe+0x2ee/0x700<br /> [ 21.673700] really_probe+0x1c6/0x6b0<br /> [ 21.673700] __driver_probe_device+0x24f/0x310<br /> [ 21.673700] driver_probe_device+0x4e/0x220<br /> [...]<br /> [ 21.673700]<br /> [ 21.673700] Allocated by task 54:<br /> [ 21.673700] kasan_save_stack+0x3d/0x60<br /> [ 21.673700] kasan_save_track+0x18/0x40<br /> [ 21.673700] kasan_save_alloc_info+0x3b/0x50<br /> [ 21.673700] __kasan_kmalloc+0x9c/0xa0<br /> [ 21.673700] __kmalloc_cache_noprof+0x139/0x340<br /> [ 21.673700] input_allocate_device+0x44/0x370<br /> [ 21.673700] hidinput_connect+0xcb6/0x2630<br /> [ 21.673700] hid_connect+0xf74/0x1d60<br /> [ 21.673700] hid_hw_start+0x8c/0x110<br /> [ 21.673700] asus_probe+0x5a3/0xf80<br /> [ 21.673700] hid_device_probe+0x2ee/0x700<br /> [ 21.673700] really_probe+0x1c6/0x6b0<br /> [ 21.673700] __driver_probe_device+0x24f/0x310<br /> [ 21.673700] driver_probe_device+0x4e/0x220<br /> [...]<br /> [ 21.673700]<br /> [ 21.673700] Freed by task 54:<br /> [ 21.673700] kasan_save_stack+0x3d/0x60<br /> [ 21.673700] kasan_save_track+0x18/0x40<br /> [ 21.673700] kasan_save_free_info+0x3f/0x60<br /> [ 21.673700] __kasan_slab_free+0x3c/0x50<br /> [ 21.673700] kfre<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix race with concurrent opens in rename(2)<br /> <br /> Besides sending the rename request to the server, the rename process<br /> also involves closing any deferred close, waiting for outstanding I/O<br /> to complete as well as marking all existing open handles as deleted to<br /> prevent them from deferring closes, which increases the race window<br /> for potential concurrent opens on the target file.<br /> <br /> Fix this by unhashing the dentry in advance to prevent any concurrent<br /> opens on the target.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: use array_index_nospec with indices that come from guest<br /> <br /> min and dest_id are guest-controlled indices. Using array_index_nospec()<br /> after the bounds checks clamps these values to mitigate speculative execution<br /> side-channels.