Vulnerabilities

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.

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).

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.

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.

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.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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)

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 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Fix deadlock in soft reset sequence<br /> <br /> The soft reset sequence is currently executed from the threaded IRQ<br /> handler, hence it cannot call disable_irq() which internally waits<br /> for IRQ handlers, i.e. itself, to complete.<br /> <br /> Use disable_irq_nosync() during a soft reset instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN<br /> <br /> uart_write_room() and uart_write() behave inconsistently when<br /> xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were<br /> never properly initialized):<br /> <br /> - uart_write_room() returns kfifo_avail() which can be &gt; 0<br /> - uart_write() checks xmit_buf and returns 0 if NULL<br /> <br /> This inconsistency causes an infinite loop in drivers that rely on<br /> tty_write_room() to determine if they can write:<br /> <br /> while (tty_write_room(tty) &gt; 0) {<br /> written = tty-&gt;ops-&gt;write(...);<br /> // written is always 0, loop never exits<br /> }<br /> <br /> For example, caif_serial&amp;#39;s handle_tx() enters an infinite loop when<br /> used with PORT_UNKNOWN serial ports, causing system hangs.<br /> <br /> Fix by making uart_write_room() also check xmit_buf and return 0 if<br /> it&amp;#39;s NULL, consistent with uart_write().<br /> <br /> Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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)