| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| UI misrepresentation in UI in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) |
| UI misrepresentation in PictureInPicture in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to spoof address bar via a crafted HTML page. (Chromium security severity: Low) |
| UI misrepresentation in Chromoting in Google Chrome on on Mac prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to spoof UI elements via crafted network traffic. (Chromium security severity: Low) |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-of-aspeed: Remove children before releasing SDC resources
Probe failure and removal leave SDHCI child devices registered after the
parent clock and managed resources are released.
Unregister the OF children in reverse order before disabling the parent
clock on both paths. Use of_platform_device_destroy() because manual
child creation does not set the flag required by of_platform_depopulate().
This issue was identified during our ongoing static-analysis research
while reviewing kernel code. |
| Spoofing issue in the DOM: Navigation component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. |
| Privilege escalation due to uninitialized memory in the Graphics: CanvasWebGL component. This vulnerability was fixed in Firefox 156, Firefox ESR 153.3, Thunderbird 156, and Thunderbird 153.3. |
| A use of uninitialized value vulnerability exists in the Matter SDK (connectedhomeip) before 1.4.0, where the `GetDestinationGroupId().Value()` method is called without first checking whether a value exists. This leads to a crash when an InvokeCommand is sent without initializing the destination group ID. The issue affects all versions before commit 0360cc3 (Dec 5, 2024) and leads to denial of service through SIGABRT. It is fixed by adding a .HasValue() check before access. |
| MathWorks Simulink before R2026b, when showing a crafted .slx file, can have blocks that are never visible in the Simulink Editor but will cause code execution. |
| A malicious webpage could repeatedly trigger external URL schemes, causing system prompts or external application launches. This could make Firefox for iOS temporarily unusable until the page is closed. This vulnerability was fixed in Firefox for iOS 155.1. |
| Spoofing issue in the Downloads component in Firefox for Android. This vulnerability was fixed in Firefox 157. |
| Zebra before 6.1.0 contains an incomplete cleanup vulnerability in the state write task that allows remote unauthenticated peers to stall node synchronization by poisoning parent_error_map. Attackers can deliver a coinbase-malleated block sharing a canonical block's hash before it propagates, causing the next canonical block to be rejected and stalling the node for roughly 2,000 blocks. |
| Uninitialized memory in the Audio/Video component. This vulnerability was fixed in Firefox ESR 153.4, Thunderbird 157, Thunderbird 140.17, Thunderbird 153.4, Firefox 157, Firefox ESR 115.42, and Firefox ESR 140.17. |
| In the Linux kernel, the following vulnerability has been resolved:
bonding: do not clear curr_active_slave prematurely when releasing all slaves
When releasing all slaves during bond destruction (all == true),
__bond_release_one() unconditionally clears bond->curr_active_slave to
NULL in every iteration.
If a backup slave is released before the active slave,
bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(),
which increments the active slave dev promiscuity counter and sets
bond_info->primary_is_promisc = 1.
Because bond->curr_active_slave was prematurely cleared to NULL when
releasing the backup slave, the subsequent iteration releasing the active
slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL)
is skipped. Consequently, bond_alb_handle_active_change() is never called
to decrement the promiscuity counter, permanently leaking promiscuous
mode on the physical device after bond teardown.
When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets
bond->curr_active_slave to NULL. We only need to avoid selecting a new
active slave when all == true. Replace the if (all) branch with
if (!all && oldcurrent == slave). |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: reset HTB scheduler topology before freeing queues
HTB offload programs NIX_AF_TLxX_TOPOLOGY on QoS-allocated scheduler
queues via otx2_qos_txschq_set_parent_topology(), but teardown freed
those queues without clearing TOPOLOGY. The AF only restores PARENT and
SCHEDULE on free, so PRIO_ANCHOR/RR_PRIO settings can survive in the
shared scheduler pool and affect later allocations.
Add otx2_qos_reset_schq_topology() and otx2_qos_free_hw_schq() to zero
TL4 through TL2 TOPOLOGY before each schq is returned to the AF during
hierarchy teardown and cfg rollback. Skip the aggregation level (TL1):
it is a per-tx-link queue shared by the PF, default Tx hierarchy and VFs,
and is not freed back to the AF by nix_txschq_free_one(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches
emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to
flush the L2/HDC data cache before fence signalling, but it never
requests a flush of the LSC untyped L1 data cache via the 'Untyped
Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11].
Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to
also flush/invalidate the untyped L1 cache, but only depending on how
HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling
between HDC Pipeline Flush and the untyped L1 cache flush no longer
holds in practice, regardless of how HDC_CHICKEN0 is programmed, so
relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan
driver (anv) has been assuming the kernel flushes both caches between
submissions, and hit user-visible corruption in apps such as Llama.cpp
because of this gap; it now works around it by flushing both caches
again from userspace at the end of every command buffer.
Correctness between submissions on the same queue is userspace's
responsibility and belongs in Mesa, not the kernel. However, for
security we must ensure stale data can't leak through the untyped L1
dataport cache once memory is reclaimed or evicted, which requires the
KMD to flush it before releasing memory for reuse.
Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for
DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline
Flush coupled to the untyped L1 cache flush, so those platforms are
unaffected. Mesa's own anv driver found that on MTL the HW
disconnected the two independently of how HDC_CHICKEN0 is programmed,
and could not bring the old behavior back even by writing the register
by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped
cache flush in 3D mode"). The kernel can't reliably request the flush
from the CS on MTL either, so restrict the new PIPE_CONTROL bit to
GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on.
Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together
with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on
Xe2 and later, so the L1 data cache is known clean before memory is
released for reuse, without depending on undocumented
platform-specific HDC_CHICKEN0 behavior.
Bspec: 56551
(cherry picked from commit 434514b6fe731e873808297c268fc52cdf4a1ce6) |
| In the Linux kernel, the following vulnerability has been resolved:
s390/crypto: Fix missing scrub of temp buffers with AES ctr and gcm algorithm
In function ctr_aes_crypt() there is a buffer used to process
remaining bytes < AES_BLOCK_SIZE. This buffer was not scrubbed and
thus could lead to expose of unwanted data. When the buffer is used
explicitly scrub it at the end of the code block to avoid exposure of
maybe sensitive data.
In a similar way the function gcm_aes_crypt() hat an error path where
the CPACF param block was not scrubbed. Instead of return early now
these error paths go to end of function where explicit scrubbing is
done. Similar with the buffers which are part of the gcm_sg_walk
structs from the variables gw_in and gw_out. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: core: Abort active target transfer on controller suspend
When an SPI controller operating in target mode has a transfer in
progress at the time of system suspend, the suspend path proceeds
without aborting the ongoing transfer. This can leave the hardware in
an inconsistent state, potentially causing the system to hang or fail
to resume cleanly.
Fix this by invoking the controller's target_abort callback from
spi_controller_suspend() when the controller is in target mode and the
callback is registered. This ensures any active target transfer is
cleanly terminated before the controller is suspended. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/pagemap: dma-unmap pages before handling migration errors
drm_pagemap_migrate_unmap_pages() relies on the pages array to determine
which pages require DMA unmapping. However,
drm_pagemap_migration_unlock_put_pages() clears the array as part of its
cleanup, leaving drm_pagemap_migrate_unmap_pages() with no valid page
information if it is called afterward.
Call drm_pagemap_migrate_unmap_pages() before
drm_pagemap_migration_unlock_put_pages() so the pages array remains
valid during DMA unmapping. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd/pmc: Fix LPS0 and debugfs leaks when STB init fails
amd_pmc_probe() registers the LPS0 s2idle handler with
acpi_register_lps0_dev() and creates the driver's debugfs directory before
calling amd_stb_s2d_init(), which is the last step in probe that can fail.
When amd_stb_s2d_init() fails (for example the S2D telemetry region cannot
be ioremapped on a long-running system, or the SMU rejects the S2D setup)
the error path only calls pci_dev_put() and returns. This leaves
amd_pmc_s2idle_dev_ops on the global lps0_s2idle_devops_head list and leaks
the debugfs directory, while the devm-managed resources backing the handler
are torn down.
Reloading the module then walks the corrupted list in
acpi_register_lps0_dev() and hits:
list_add corruption. next->prev should be prev, but was NULL.
kernel BUG at lib/list_debug.c:29!
acpi_register_lps0_dev+0x44/0x80
amd_pmc_probe+0x224/0x380 [amd_pmc]
platform_probe+0x67/0x90
Even without a reload, the stale registration means the next s2idle
transition calls into torn-down driver state.
Unwind the debugfs directory and the LPS0 registration on the
amd_stb_s2d_init() error path. acpi_unregister_lps0_dev() is safe to call
unconditionally here: it is guarded on the same conditions as
acpi_register_lps0_dev(), which is exactly what amd_pmc_remove() already
relies on. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: unregister debugfs entries on teardown
ucsi_register() creates per-instance debugfs entries, but
ucsi_unregister() keeps them around until ucsi_destroy().
Drivers like ucsi_glink that unregister/register the same UCSI
instance across remoteproc restart then try to create an already
existing debugfs directory and log:
debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'
Unregister debugfs entries as part of ucsi_unregister(), and
clear ucsi->debugfs after freeing it so repeated unregister
paths remain safe. |
