Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix use-after-free on controller registration failure<br /> <br /> Make sure to deregister from driver core also in the unlikely event that<br /> per-cpu statistics allocation fails during controller registration to<br /> avoid use-after-free (of driver resources) and unclocked register<br /> accesses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix memory leak in xe_vm_madvise_ioctl<br /> <br /> When check_bo_args_are_sane() validation fails, jump to the new<br /> free_vmas cleanup label to properly free the allocated resources.<br /> This ensures proper cleanup in this error path.<br /> <br /> (cherry picked from commit 29bd06faf727a4b76663e4be0f7d770e2d2a7965)

*** Pendiente de traducción *** FastMCP is the standard framework for building MCP applications. Prior to version 3.2.0, while testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user&amp;#39;s consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability. This issue has been patched in version 3.2.0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: fix multishot recv missing EOF on wakeup race<br /> <br /> When a socket send and shutdown() happen back-to-back, both fire<br /> wake-ups before the receiver&amp;#39;s task_work has a chance to run. The first<br /> wake gets poll ownership (poll_refs=1), and the second bumps it to 2.<br /> When io_poll_check_events() runs, it calls io_poll_issue() which does a<br /> recv that reads the data and returns IOU_RETRY. The loop then drains all<br /> accumulated refs (atomic_sub_return(2) -&gt; 0) and exits, even though only<br /> the first event was consumed. Since the shutdown is a persistent state<br /> change, no further wakeups will happen, and the multishot recv can hang<br /> forever.<br /> <br /> Check specifically for HUP in the poll loop, and ensure that another<br /> loop is done to check for status if more than a single poll activation<br /> is pending. This ensures we don&amp;#39;t lose the shutdown event.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: Avoid boot crash in RedBoot partition table parser<br /> <br /> Given CONFIG_FORTIFY_SOURCE=y and a recent compiler,<br /> commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() when<br /> available") produces the warning below and an oops.<br /> <br /> Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000<br /> ------------[ cut here ]------------<br /> WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1<br /> memcmp: detected buffer overflow: 15 byte read of buffer size 14<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE<br /> <br /> As Kees said, "&amp;#39;names&amp;#39; is pointing to the final &amp;#39;namelen&amp;#39; many bytes<br /> of the allocation ... &amp;#39;namelen&amp;#39; could be basically any length at all.<br /> This fortify warning looks legit to me -- this code used to be reading<br /> beyond the end of the allocation."<br /> <br /> Since the size of the dynamic allocation is calculated with strlen()<br /> we can use strcmp() instead of memcmp() and remain within bounds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix statistics allocation<br /> <br /> The controller per-cpu statistics is not allocated until after the<br /> controller has been registered with driver core, which leaves a window<br /> where accessing the sysfs attributes can trigger a NULL-pointer<br /> dereference.<br /> <br /> Fix this by moving the statistics allocation to controller allocation<br /> while tying its lifetime to that of the controller (rather than using<br /> implicit devres).

*** Pendiente de traducción *** Budibase is an open-source low-code platform. Prior to version 3.23.25, a business logic vulnerability exists in Budibase’s password reset functionality due to the absence of rate limiting, CAPTCHA, or abuse prevention mechanisms on the “Forgot Password” endpoint. An unauthenticated attacker can repeatedly trigger password reset requests for the same email address, resulting in hundreds of password reset emails being sent in a short time window. This enables large-scale email flooding, user harassment, denial of service (DoS) against user inboxes, and potential financial and reputational impact for Budibase. This issue has been patched in version 3.23.25.

*** Pendiente de traducción *** Budibase is an open-source low-code platform. Prior to version 3.33.4, the bash automation step executes user-provided commands using execSync without proper sanitization or validation. User input is processed through processStringSync which allows template interpolation, potentially allowing arbitrary command execution. This issue has been patched in version 3.33.4.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Open-code GGTT MMIO access protection<br /> <br /> GGTT MMIO access is currently protected by hotplug (drm_dev_enter),<br /> which works correctly when the driver loads successfully and is later<br /> unbound or unloaded. However, if driver load fails, this protection is<br /> insufficient because drm_dev_unplug() is never called.<br /> <br /> Additionally, devm release functions cannot guarantee that all BOs with<br /> GGTT mappings are destroyed before the GGTT MMIO region is removed, as<br /> some BOs may be freed asynchronously by worker threads.<br /> <br /> To address this, introduce an open-coded flag, protected by the GGTT<br /> lock, that guards GGTT MMIO access. The flag is cleared during the<br /> dev_fini_ggtt devm release function to ensure MMIO access is disabled<br /> once teardown begins.<br /> <br /> (cherry picked from commit 4f3a998a173b4325c2efd90bdadc6ccd3ad9a431)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dmc: Fix an unlikely NULL pointer deference at probe<br /> <br /> intel_dmc_update_dc6_allowed_count() oopses when DMC hasn&amp;#39;t been<br /> initialized, and dmc is thus NULL.<br /> <br /> That would be the case when the call path is<br /> intel_power_domains_init_hw() -&gt; {skl,bxt,icl}_display_core_init() -&gt;<br /> gen9_set_dc_state() -&gt; intel_dmc_update_dc6_allowed_count(), as<br /> intel_power_domains_init_hw() is called *before* intel_dmc_init().<br /> <br /> However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()<br /> conditionally, depending on the current and target DC states. At probe,<br /> the target is disabled, but if DC6 is enabled, the function is called,<br /> and an oops follows. Apparently it&amp;#39;s quite unlikely that DC6 is enabled<br /> at probe, as we haven&amp;#39;t seen this failure mode before.<br /> <br /> It is also strange to have DC6 enabled at boot, since that would require<br /> the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and<br /> the driver stopping / reprogramming the firmware is a poorly specified<br /> sequence and as such unlikely an intentional BIOS behaviour. It&amp;#39;s more<br /> likely that BIOS is leaving an unintentionally enabled DC6 HW state<br /> behind (without actually loading the required DMC firmware for this).<br /> <br /> The tracking of the DC6 allowed counter only works if starting /<br /> stopping the counter depends on the _SW_ DC6 state vs. the current _HW_<br /> DC6 state (since stopping the counter requires the DC5 counter captured<br /> when the counter was started). Thus, using the HW DC6 state is incorrect<br /> and it also leads to the above oops. Fix both issues by using the SW DC6<br /> state for the tracking.<br /> <br /> This is v2 of the fix originally sent by Jani, updated based on the<br /> first Link: discussion below.<br /> <br /> (cherry picked from commit 2344b93af8eb5da5d496b4e0529d35f0f559eaf0)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Limit BO list entry count to prevent resource exhaustion<br /> <br /> Userspace can pass an arbitrary number of BO list entries via the<br /> bo_number field. Although the previous multiplication overflow check<br /> prevents out-of-bounds allocation, a large number of entries could still<br /> cause excessive memory allocation (up to potentially gigabytes) and<br /> unnecessarily long list processing times.<br /> <br /> Introduce a hard limit of 128k entries per BO list, which is more than<br /> sufficient for any realistic use case (e.g., a single list containing all<br /> buffers in a large scene). This prevents memory exhaustion attacks and<br /> ensures predictable performance.<br /> <br /> Return -EINVAL if the requested entry count exceeds the limit<br /> <br /> (cherry picked from commit 688b87d39e0aa8135105b40dc167d74b5ada5332)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Synchronize interrupts before suspending the GPU<br /> <br /> The runtime PM suspend callback doesn&amp;#39;t know whether the IRQ handler is<br /> in progress on a different CPU core and doesn&amp;#39;t wait for it to finish.<br /> <br /> Depending on timing, the IRQ handler could be running while the GPU is<br /> suspended, leading to kernel crashes when trying to access GPU<br /> registers. See example signature below.<br /> <br /> In a power off sequence initiated by the runtime PM suspend callback,<br /> wait for any IRQ handlers in progress on other CPU cores to finish, by<br /> calling synchronize_irq().<br /> <br /> At the same time, remove the runtime PM resume/put calls in the threaded<br /> IRQ handler. On top of not being the right approach to begin with, and<br /> being at the wrong place as they should have wrapped all GPU register<br /> accesses, the driver would hit a deadlock between synchronize_irq()<br /> being called from a runtime PM suspend callback, holding the device<br /> power lock, and the resume callback requiring the same.<br /> <br /> Example crash signature on a TI AM68 SK platform:<br /> <br /> [ 337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError<br /> [ 337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT<br /> [ 337.241246] Tainted: [M]=MACHINE_CHECK<br /> [ 337.241249] Hardware name: Texas Instruments AM68 SK (DT)<br /> [ 337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 337.241256] pc : pvr_riscv_irq_pending+0xc/0x24<br /> [ 337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310<br /> [ 337.241282] sp : ffff800085b0bd30<br /> [ 337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10<br /> [ 337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000<br /> [ 337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30<br /> [ 337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001<br /> [ 337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40<br /> [ 337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a<br /> [ 337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00<br /> [ 337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003<br /> [ 337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000<br /> [ 337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000<br /> [ 337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt<br /> [ 337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G M 6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT<br /> [ 337.241342] Tainted: [M]=MACHINE_CHECK<br /> [ 337.241343] Hardware name: Texas Instruments AM68 SK (DT)<br /> [ 337.241345] Call trace:<br /> [ 337.241348] show_stack+0x18/0x24 (C)<br /> [ 337.241357] dump_stack_lvl+0x60/0x80<br /> [ 337.241364] dump_stack+0x18/0x24<br /> [ 337.241368] vpanic+0x124/0x2ec<br /> [ 337.241373] abort+0x0/0x4<br /> [ 337.241377] add_taint+0x0/0xbc<br /> [ 337.241384] arm64_serror_panic+0x70/0x80<br /> [ 337.241389] do_serror+0x3c/0x74<br /> [ 337.241392] el1h_64_error_handler+0x30/0x48<br /> [ 337.241400] el1h_64_error+0x6c/0x70<br /> [ 337.241404] pvr_riscv_irq_pending+0xc/0x24 (P)<br /> [ 337.241410] irq_thread_fn+0x2c/0xb0<br /> [ 337.241416] irq_thread+0x170/0x334<br /> [ 337.241421] kthread+0x12c/0x210<br /> [ 337.241428] ret_from_fork+0x10/0x20<br /> [ 337.241434] SMP: stopping secondary CPUs<br /> [ 337.241451] Kernel Offset: disabled<br /> [ 337.241453] CPU features: 0x040000,02002800,20002001,0400421b<br /> [ 337.241456] Memory Limit: none<br /> [ 337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---