Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: serialize lock/unlock against other NAND operations<br /> <br /> nand_lock() and nand_unlock() call into chip-&gt;ops.lock_area/unlock_area<br /> without holding the NAND device lock. On controllers that implement<br /> SET_FEATURES via multiple low-level PIO commands, these can race with<br /> concurrent UBI/UBIFS background erase/write operations that hold the<br /> device lock, resulting in cmd_pending conflicts on the NAND controller.<br /> <br /> Add nand_get_device()/nand_release_device() around the lock/unlock<br /> operations to serialize them against all other NAND controller access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm_mpam: Fix null pointer dereference when restoring bandwidth counters<br /> <br /> When an MSC supporting memory bandwidth monitoring is brought offline and<br /> then online, mpam_restore_mbwu_state() calls __ris_msmon_read() via ipi to<br /> restore the configuration of the bandwidth counters. It doesn&amp;#39;t care about<br /> the value read, mbwu_arg.val, and doesn&amp;#39;t set it leading to a null pointer<br /> dereference when __ris_msmon_read() adds to it. This results in a kernel<br /> oops with a call trace such as:<br /> <br /> Call trace:<br /> __ris_msmon_read+0x19c/0x64c (P)<br /> mpam_restore_mbwu_state+0xa0/0xe8<br /> smp_call_on_cpu_callback+0x1c/0x38<br /> process_one_work+0x154/0x4b4<br /> worker_thread+0x188/0x310<br /> kthread+0x11c/0x130<br /> ret_from_fork+0x10/0x20<br /> <br /> Provide a local variable for val to avoid __ris_msmon_read() dereferencing<br /> a null pointer when adding to val.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic-spisg: Fix memory leak in aml_spisg_probe()<br /> <br /> In aml_spisg_probe(), ctlr is allocated by<br /> spi_alloc_target()/spi_alloc_host(), but fails to call<br /> spi_controller_put() in several error paths. This leads<br /> to a memory leak whenever the driver fails to probe after<br /> the initial allocation.<br /> <br /> Convert to use devm_spi_alloc_host()/devm_spi_alloc_target()<br /> to fix the memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Don&amp;#39;t overwrite KMS surface dirty tracker<br /> <br /> We were overwriting the surface&amp;#39;s dirty tracker here causing a memory leak.

*** Pendiente de traducción *** FastMCP is the standard framework for building MCP applications. Prior to version 3.2.0, server names containing shell metacharacters (e.g., &amp;) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string. This issue has been patched in version 3.2.0.

*** Pendiente de traducción *** Juju is an open source application orchestration engine that enables any application operation on any infrastructure at any scale through special operators called ‘charms’. From versions 2.9 to before 2.9.56 and 3.6 to before 3.6.19, it is possible that a compromised workload machine under a Juju controller can read any log file for any entity in any model at any level. This issue has been patched in versions 2.9.56 and 3.6.19.

*** Pendiente de traducción *** Juju is an open source application orchestration engine that enables any application operation on any infrastructure at any scale through special operators called ‘charms’. From versions 2.9 to before 2.9.56 and 3.6 to before 3.6.19, any authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller. This issue has been patched in versions 2.9.56 and 3.6.19.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in durable v2 replay of active file handles<br /> <br /> parse_durable_handle_context() unconditionally assigns dh_info-&gt;fp-&gt;conn<br /> to the current connection when handling a DURABLE_REQ_V2 context with<br /> SMB2_FLAGS_REPLAY_OPERATION. ksmbd_lookup_fd_cguid() does not filter by<br /> fp-&gt;conn, so it returns file handles that are already actively connected.<br /> The unconditional overwrite replaces fp-&gt;conn, and when the overwriting<br /> connection is subsequently freed, __ksmbd_close_fd() dereferences the<br /> stale fp-&gt;conn via spin_lock(&amp;fp-&gt;conn-&gt;llist_lock), causing a<br /> use-after-free.<br /> <br /> KASAN report:<br /> <br /> [ 7.349357] ==================================================================<br /> [ 7.349607] BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x75/0xe0<br /> [ 7.349811] Write of size 4 at addr ffff8881056ac18c by task kworker/1:2/108<br /> [ 7.350010]<br /> [ 7.350064] CPU: 1 UID: 0 PID: 108 Comm: kworker/1:2 Not tainted 7.0.0-rc3+ #58 PREEMPTLAZY<br /> [ 7.350068] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 7.350070] Workqueue: ksmbd-io handle_ksmbd_work<br /> [ 7.350083] Call Trace:<br /> [ 7.350087] <br /> [ 7.350087] dump_stack_lvl+0x64/0x80<br /> [ 7.350094] print_report+0xce/0x660<br /> [ 7.350100] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 7.350101] ? __pfx___mod_timer+0x10/0x10<br /> [ 7.350106] ? _raw_spin_lock+0x75/0xe0<br /> [ 7.350108] kasan_report+0xce/0x100<br /> [ 7.350109] ? _raw_spin_lock+0x75/0xe0<br /> [ 7.350114] kasan_check_range+0x105/0x1b0<br /> [ 7.350116] _raw_spin_lock+0x75/0xe0<br /> [ 7.350118] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 7.350119] ? __call_rcu_common.constprop.0+0x25e/0x780<br /> [ 7.350125] ? close_id_del_oplock+0x2cc/0x4e0<br /> [ 7.350128] __ksmbd_close_fd+0x27f/0xaf0<br /> [ 7.350131] ksmbd_close_fd+0x135/0x1b0<br /> [ 7.350133] smb2_close+0xb19/0x15b0<br /> [ 7.350142] ? __pfx_smb2_close+0x10/0x10<br /> [ 7.350143] ? xas_load+0x18/0x270<br /> [ 7.350146] ? _raw_spin_lock+0x84/0xe0<br /> [ 7.350148] ? __pfx__raw_spin_lock+0x10/0x10<br /> [ 7.350150] ? _raw_spin_unlock+0xe/0x30<br /> [ 7.350151] ? ksmbd_smb2_check_message+0xeb2/0x24c0<br /> [ 7.350153] ? ksmbd_tree_conn_lookup+0xcd/0xf0<br /> [ 7.350154] handle_ksmbd_work+0x40f/0x1080<br /> [ 7.350156] process_one_work+0x5fa/0xef0<br /> [ 7.350162] ? assign_work+0x122/0x3e0<br /> [ 7.350163] worker_thread+0x54b/0xf70<br /> [ 7.350165] ? __pfx_worker_thread+0x10/0x10<br /> [ 7.350166] kthread+0x346/0x470<br /> [ 7.350170] ? recalc_sigpending+0x19b/0x230<br /> [ 7.350176] ? __pfx_kthread+0x10/0x10<br /> [ 7.350178] ret_from_fork+0x4fb/0x6c0<br /> [ 7.350183] ? __pfx_ret_from_fork+0x10/0x10<br /> [ 7.350185] ? __switch_to+0x36c/0xbe0<br /> [ 7.350188] ? __pfx_kthread+0x10/0x10<br /> [ 7.350190] ret_from_fork_asm+0x1a/0x30<br /> [ 7.350197] <br /> [ 7.350197]<br /> [ 7.355160] Allocated by task 123:<br /> [ 7.355261] kasan_save_stack+0x33/0x60<br /> [ 7.355373] kasan_save_track+0x14/0x30<br /> [ 7.355484] __kasan_kmalloc+0x8f/0xa0<br /> [ 7.355593] ksmbd_conn_alloc+0x44/0x6d0<br /> [ 7.355711] ksmbd_kthread_fn+0x243/0xd70<br /> [ 7.355839] kthread+0x346/0x470<br /> [ 7.355942] ret_from_fork+0x4fb/0x6c0<br /> [ 7.356051] ret_from_fork_asm+0x1a/0x30<br /> [ 7.356164]<br /> [ 7.356214] Freed by task 134:<br /> [ 7.356305] kasan_save_stack+0x33/0x60<br /> [ 7.356416] kasan_save_track+0x14/0x30<br /> [ 7.356527] kasan_save_free_info+0x3b/0x60<br /> [ 7.356646] __kasan_slab_free+0x43/0x70<br /> [ 7.356761] kfree+0x1ca/0x430<br /> [ 7.356862] ksmbd_tcp_disconnect+0x59/0xe0<br /> [ 7.356993] ksmbd_conn_handler_loop+0x77e/0xd40<br /> [ 7.357138] kthread+0x346/0x470<br /> [ 7.357240] ret_from_fork+0x4fb/0x6c0<br /> [ 7.357350] ret_from_fork_asm+0x1a/0x30<br /> [ 7.357463]<br /> [ 7.357513] The buggy address belongs to the object at ffff8881056ac000<br /> [ 7.357513] which belongs to the cache kmalloc-1k of size 1024<br /> [ 7.357857] The buggy address is located 396 bytes inside of<br /> [ 7.357857] freed 1024-byte region <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free of share_conf in compound request<br /> <br /> smb2_get_ksmbd_tcon() reuses work-&gt;tcon in compound requests without<br /> validating tcon-&gt;t_state. ksmbd_tree_conn_lookup() checks t_state ==<br /> TREE_CONNECTED on the initial lookup path, but the compound reuse path<br /> bypasses this check entirely.<br /> <br /> If a prior command in the compound (SMB2_TREE_DISCONNECT) sets t_state<br /> to TREE_DISCONNECTED and frees share_conf via ksmbd_share_config_put(),<br /> subsequent commands dereference the freed share_conf through<br /> work-&gt;tcon-&gt;share_conf.<br /> <br /> KASAN report:<br /> <br /> [ 4.144653] ==================================================================<br /> [ 4.145059] BUG: KASAN: slab-use-after-free in smb2_write+0xc74/0xe70<br /> [ 4.145415] Read of size 4 at addr ffff88810430c194 by task kworker/1:1/44<br /> [ 4.145772]<br /> [ 4.145867] CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted 7.0.0-rc3+ #60 PREEMPTLAZY<br /> [ 4.145871] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 4.145875] Workqueue: ksmbd-io handle_ksmbd_work<br /> [ 4.145888] Call Trace:<br /> [ 4.145892] <br /> [ 4.145894] dump_stack_lvl+0x64/0x80<br /> [ 4.145910] print_report+0xce/0x660<br /> [ 4.145919] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 4.145928] ? smb2_write+0xc74/0xe70<br /> [ 4.145931] kasan_report+0xce/0x100<br /> [ 4.145934] ? smb2_write+0xc74/0xe70<br /> [ 4.145937] smb2_write+0xc74/0xe70<br /> [ 4.145939] ? __pfx_smb2_write+0x10/0x10<br /> [ 4.145942] ? _raw_spin_unlock+0xe/0x30<br /> [ 4.145945] ? ksmbd_smb2_check_message+0xeb2/0x24c0<br /> [ 4.145948] ? smb2_tree_disconnect+0x31c/0x480<br /> [ 4.145951] handle_ksmbd_work+0x40f/0x1080<br /> [ 4.145953] process_one_work+0x5fa/0xef0<br /> [ 4.145962] ? assign_work+0x122/0x3e0<br /> [ 4.145964] worker_thread+0x54b/0xf70<br /> [ 4.145967] ? __pfx_worker_thread+0x10/0x10<br /> [ 4.145970] kthread+0x346/0x470<br /> [ 4.145976] ? recalc_sigpending+0x19b/0x230<br /> [ 4.145980] ? __pfx_kthread+0x10/0x10<br /> [ 4.145984] ret_from_fork+0x4fb/0x6c0<br /> [ 4.145992] ? __pfx_ret_from_fork+0x10/0x10<br /> [ 4.145995] ? __switch_to+0x36c/0xbe0<br /> [ 4.145999] ? __pfx_kthread+0x10/0x10<br /> [ 4.146003] ret_from_fork_asm+0x1a/0x30<br /> [ 4.146013] <br /> [ 4.146014]<br /> [ 4.149858] Allocated by task 44:<br /> [ 4.149953] kasan_save_stack+0x33/0x60<br /> [ 4.150061] kasan_save_track+0x14/0x30<br /> [ 4.150169] __kasan_kmalloc+0x8f/0xa0<br /> [ 4.150274] ksmbd_share_config_get+0x1dd/0xdd0<br /> [ 4.150401] ksmbd_tree_conn_connect+0x7e/0x600<br /> [ 4.150529] smb2_tree_connect+0x2e6/0x1000<br /> [ 4.150645] handle_ksmbd_work+0x40f/0x1080<br /> [ 4.150761] process_one_work+0x5fa/0xef0<br /> [ 4.150873] worker_thread+0x54b/0xf70<br /> [ 4.150978] kthread+0x346/0x470<br /> [ 4.151071] ret_from_fork+0x4fb/0x6c0<br /> [ 4.151176] ret_from_fork_asm+0x1a/0x30<br /> [ 4.151286]<br /> [ 4.151332] Freed by task 44:<br /> [ 4.151418] kasan_save_stack+0x33/0x60<br /> [ 4.151526] kasan_save_track+0x14/0x30<br /> [ 4.151634] kasan_save_free_info+0x3b/0x60<br /> [ 4.151751] __kasan_slab_free+0x43/0x70<br /> [ 4.151861] kfree+0x1ca/0x430<br /> [ 4.151952] __ksmbd_tree_conn_disconnect+0xc8/0x190<br /> [ 4.152088] smb2_tree_disconnect+0x1cd/0x480<br /> [ 4.152211] handle_ksmbd_work+0x40f/0x1080<br /> [ 4.152326] process_one_work+0x5fa/0xef0<br /> [ 4.152438] worker_thread+0x54b/0xf70<br /> [ 4.152545] kthread+0x346/0x470<br /> [ 4.152638] ret_from_fork+0x4fb/0x6c0<br /> [ 4.152743] ret_from_fork_asm+0x1a/0x30<br /> [ 4.152853]<br /> [ 4.152900] The buggy address belongs to the object at ffff88810430c180<br /> [ 4.152900] which belongs to the cache kmalloc-96 of size 96<br /> [ 4.153226] The buggy address is located 20 bytes inside of<br /> [ 4.153226] freed 96-byte region [ffff88810430c180, ffff88810430c1e0)<br /> [ 4.153549]<br /> [ 4.153596] The buggy address belongs to the physical page:<br /> [ 4.153750] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88810430ce80 pfn:0x10430c<br /> [ 4.154000] flags: 0x<br /> ---truncated---

*** Pendiente de traducción *** A weakness has been identified in Casdoor 2.356.0. This vulnerability affects unknown code of the component Webhook URL Handler. Executing a manipulation can lead to server-side request forgery. The attack can be launched remotely. The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** An issue in Dokuwiki v.2025-05-14b "Librarian" [56.2] allows a remote attacker to cause a denial of service via the media_upload_xhr() function in the media.php file

*** Pendiente de traducción *** An issue was discovered in Biztalk360 before 11.5. Because of incorrect access control, any user is able to request the loading a DLL file. During the loading, a method is called. An attacker can craft a malicious DLL, upload it to the server, and use it to achieve remote code execution on the server.