Vulnerabilidades

*** 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Avoid undefined behavior from stopping/starting inactive events<br /> <br /> Calling pmu-&gt;start()/stop() on perf events in PERF_EVENT_STATE_OFF can<br /> leave event-&gt;hw.idx at -1. When PMU drivers later attempt to use this<br /> negative index as a shift exponent in bitwise operations, it leads to UBSAN<br /> shift-out-of-bounds reports.<br /> <br /> The issue is a logical flaw in how event groups handle throttling when some<br /> members are intentionally disabled. Based on the analysis and the<br /> reproducer provided by Mark Rutland (this issue on both arm64 and x86-64).<br /> <br /> The scenario unfolds as follows:<br /> <br /> 1. A group leader event is configured with a very aggressive sampling<br /> period (e.g., sample_period = 1). This causes frequent interrupts and<br /> triggers the throttling mechanism.<br /> 2. A child event in the same group is created in a disabled state<br /> (.disabled = 1). This event remains in PERF_EVENT_STATE_OFF.<br /> Since it hasn&amp;#39;t been scheduled onto the PMU, its event-&gt;hw.idx remains<br /> initialized at -1.<br /> 3. When throttling occurs, perf_event_throttle_group() and later<br /> perf_event_unthrottle_group() iterate through all siblings, including<br /> the disabled child event.<br /> 4. perf_event_throttle()/unthrottle() are called on this inactive child<br /> event, which then call event-&gt;pmu-&gt;start()/stop().<br /> 5. The PMU driver receives the event with hw.idx == -1 and attempts to<br /> use it as a shift exponent. e.g., in macros like PMCNTENSET(idx),<br /> leading to the UBSAN report.<br /> <br /> The throttling mechanism attempts to start/stop events that are not<br /> actively scheduled on the hardware.<br /> <br /> Move the state check into perf_event_throttle()/perf_event_unthrottle() so<br /> that inactive events are skipped entirely. This ensures only active events<br /> with a valid hw.idx are processed, preventing undefined behavior and<br /> silencing UBSAN warnings. The corrected check ensures true before<br /> proceeding with PMU operations.<br /> <br /> The problem can be reproduced with the syzkaller reproducer:

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/kbuf: fix signedness in this_len calculation<br /> <br /> When importing and using buffers, buf-&gt;len is considered unsigned.<br /> However, buf-&gt;len is converted to signed int when committing. This can<br /> lead to unexpected behavior if the buffer is large enough to be<br /> interpreted as a negative value. Make min_t calculation unsigned.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Add a null ptr check for dpu_encoder_needs_modeset<br /> <br /> The drm_atomic_get_new_connector_state() can return NULL if the<br /> connector is not part of the atomic state. Add a check to prevent<br /> a NULL pointer dereference.<br /> <br /> This follows the same pattern used in dpu_encoder_update_topology()<br /> within the same file, which checks for NULL before using conn_state.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/665188/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/smb: Fix inconsistent refcnt update<br /> <br /> A possible inconsistent update of refcount was identified in `smb2_compound_op`.<br /> Such inconsistent update could lead to possible resource leaks.<br /> <br /> Why it is a possible bug:<br /> 1. In the comment section of the function, it clearly states that the<br /> reference to `cfile` should be dropped after calling this function.<br /> 2. Every control flow path would check and drop the reference to<br /> `cfile`, except the patched one.<br /> 3. Existing callers would not handle refcount update of `cfile` if<br /> -ENOMEM is returned.<br /> <br /> To fix the bug, an extra goto label "out" is added, to make sure that the<br /> cleanup logic would always be respected. As the problem is caused by the<br /> allocation failure of `vars`, the cleanup logic between label "finished"<br /> and "out" can be safely ignored. According to the definition of function<br /> `is_replayable_error`, the error code of "-ENOMEM" is not recoverable.<br /> Therefore, the replay logic also gets ignored.