Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: restore failed global reservations to subpool<br /> <br /> Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool")<br /> fixed an underflow error for hstate-&gt;resv_huge_pages caused by incorrectly<br /> attributing globally requested pages to the subpool&amp;#39;s reservation.<br /> <br /> Unfortunately, this fix also introduced the opposite problem, which would<br /> leave spool-&gt;used_hpages elevated if the globally requested pages could<br /> not be acquired. This is because while a subpool&amp;#39;s reserve pages only<br /> accounts for what is requested and allocated from the subpool, its "used"<br /> counter keeps track of what is consumed in total, both from the subpool<br /> and globally. Thus, we need to adjust spool-&gt;used_hpages in the other<br /> direction, and make sure that globally requested pages are uncharged from<br /> the subpool&amp;#39;s used counter.<br /> <br /> Each failed allocation attempt increments the used_hpages counter by how<br /> many pages were requested from the global pool. Ultimately, this renders<br /> the subpool unusable, as used_hpages approaches the max limit.<br /> <br /> The issue can be reproduced as follows:<br /> 1. Allocate 4 hugetlb pages<br /> 2. Create a hugetlb mount with max=4, min=2<br /> 3. Consume 2 pages globally<br /> 4. Request 3 pages from the subpool (2 from subpool + 1 from global)<br /> 4.1 hugepage_subpool_get_pages(spool, 3) succeeds.<br /> used_hpages += 3<br /> 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left<br /> used_hpages -= 2<br /> 5. Subpool now has used_hpages = 1, despite not being able to<br /> successfully allocate any hugepages. It believes it can now only<br /> allocate 3 more hugepages, not 4.<br /> <br /> With each failed allocation attempt incrementing the used counter, the<br /> subpool eventually reaches a point where its used counter equals its<br /> max counter. At that point, any future allocations that try to<br /> allocate hugeTLB pages from the subpool will fail, despite the subpool<br /> not having any of its hugeTLB pages consumed by any user.<br /> <br /> Once this happens, there is no way to make the subpool usable again,<br /> since there is no way to decrement the used counter as no process is<br /> really consuming the hugeTLB pages.<br /> <br /> The underflow issue that the original commit fixes still remains fixed<br /> as well.<br /> <br /> Without this fix, used_hpages would keep on leaking if<br /> hugetlb_acct_memory() fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: do not access current-&gt;mems_allowed_seq if !allow_spin<br /> <br /> Lockdep complains when get_from_any_partial() is called in an NMI<br /> context, because current-&gt;mems_allowed_seq is seqcount_spinlock_t and<br /> not NMI-safe:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N<br /> --------------------------------<br /> inconsistent {INITIAL USE} -&gt; {IN-NMI} usage.<br /> kunit_try_catch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes:<br /> ffff889085799820 (&amp;____s-&gt;seqcount#3){.-.-}-{0:0}, at: ___slab_alloc+0x58f/0xc00<br /> {INITIAL USE} state was registered at:<br /> lock_acquire+0x185/0x320<br /> kernel_init_freeable+0x391/0x1150<br /> kernel_init+0x1f/0x220<br /> ret_from_fork+0x736/0x8f0<br /> ret_from_fork_asm+0x1a/0x30<br /> irq event stamp: 56<br /> hardirqs last enabled at (55): [] _raw_spin_unlock_irq+0x27/0x70<br /> hardirqs last disabled at (56): [] __schedule+0x2a8a/0x6630<br /> softirqs last enabled at (0): [] copy_process+0x1dc1/0x6a10<br /> softirqs last disabled at (0): [] 0x0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;____s-&gt;seqcount#3);<br /> <br /> lock(&amp;____s-&gt;seqcount#3);<br /> <br /> *** DEADLOCK ***<br /> <br /> According to Documentation/locking/seqlock.rst, seqcount_t is not<br /> NMI-safe and seqcount_latch_t should be used when read path can interrupt<br /> the write-side critical section. In this case, do not access<br /> current-&gt;mems_allowed_seq and avoid retry.

*** Pendiente de traducción *** ai-scanner is an AI model safety scanner built on NVIDIA garak. From version 1.0.0 to before version 1.4.1, there is a remote code execution vulnerability via JavaScript injection in `BrowserAutomation::PlaywrightService`. This issue has been patched in version 1.4.1.

*** Pendiente de traducción *** math-codegen generates code from mathematical expressions. Prior to version 0.4.3, string literal content passed to cg.parse() is injected verbatim into a new Function() body without sanitization. This allows an attacker to execute arbitrary system commands when user-controlled input reaches the parser. Any application exposing a math evaluation endpoint where user input flows into cg.parse() is vulnerable to full RCE. This issue has been patched in version 0.4.3.

*** Pendiente de traducción *** CROSS implementation contains reference and optimized implementations of the CROSS post-quantum signature algorithm. Prior to commit fc6b7e7, there is a buffer overflow in crypto_sign_open() caused by an underflow of the integer mlen. This issue has been patched via commit fc6b7e7.

*** Pendiente de traducción *** PraisonAI is a multi-agent teams system. Prior to version 4.6.9, the fix for PraisonAI&amp;#39;s MCP command handling does not add a command allowlist or argument validation to parse_mcp_command(), allowing arbitrary executables like bash, python, or /bin/sh with inline code execution flags to pass through to subprocess execution. This issue has been patched in version 4.6.9.

*** Pendiente de traducción *** PraisonAI is a multi-agent teams system. Prior to praisonai version 4.6.9 and praisonaiagents version 1.6.9, the fix for CVE-2026-40315 added input validation to SQLiteConversationStore only. Nine sibling backends — MySQL, PostgreSQL, async SQLite/MySQL/PostgreSQL, Turso, SingleStore, Supabase, SurrealDB — pass table_prefix straight into f-string SQL. Same root cause, same code pattern, same exploitation. 52 unvalidated injection points across the codebase. postgres.py additionally accepts an unvalidated schema parameter used directly in DDL. This issue has been patched in praisonai version 4.6.9 and praisonaiagents version 1.6.9.

*** Pendiente de traducción *** go-git is an extensible git implementation library written in pure Go. Prior to versions 5.18.0 and 6.0.0-alpha.2, go-git may leak HTTP authentication credentials when following redirects during smart-HTTP clone and fetch operations. This issue has been patched in versions 5.18.0 and 6.0.0-alpha.2.

*** Pendiente de traducción *** YARD is a Ruby Documentation tool. Prior to version 0.9.42, a path traversal vulnerability was discovered in YARD when using yard server to serve documentation. This bug would allow unsanitized HTTP requests to access arbitrary files on the machine of a yard server host under certain conditions. This issue has been patched in version 0.9.42.

*** Pendiente de traducción *** Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge. From versions 1.3.0 to before 1.15.14, 1.16.0-rc.1 to before 1.16.14, and 1.17.0-rc.1 to before 1.17.5, a vulnerability has been found in Dapr that allows bypassing access control policies for service invocation using reserved URL characters and path traversal sequences in method paths. The ACL normalized the method path independently from the dispatch layer, so the ACL evaluated one path while the target application received a different one. This issue has been patched in versions 1.15.14, 1.16.14, and 1.17.5.

*** Pendiente de traducción *** Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to versions 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8, a Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server due to improper handling of URLs during Server-Side Rendering (SSR). When an attacker sends a request such as GET /\evil.com/ HTTP/1.1 the server engine (Express, etc.) passes the URL string to Angular’s rendering functions. Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is evil.com. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services. This issue has been patched in versions 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8.

*** Pendiente de traducción *** Sync-in Server is a secure, open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.2.0, the /api/auth/login endpoint contains a logic flaw that allows unauthenticated remote attackers to enumerate valid usernames by measuring the application&amp;#39;s response time. This issue has been patched in version 2.2.0.