| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
greybus: audio: bound the topology section sizes against the fetched size
gb_audio_gb_get_topology() fetches a topology blob of a module-supplied
size, and gbaudio_tplg_parse_data() then walks it by adding the
module-supplied size_dais, size_controls and size_widgets fields to
form the control, widget and route section offsets. Those le32 sizes
are never checked against the fetched blob, so a module reporting a
small topology size but large section sizes makes the offsets point
past the allocation, and parsing reads out of bounds.
Reject a topology whose section sizes do not fit within the fetched
size before it is parsed. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI/pwrctrl: tc9563: Fix parsing the integrated Ethernet MAC Endpoint node
DSP3 has an integrated Ethernet MAC Endpoint which has its own set of
config registers for configuring settings such as ASPM. The Endpoint device
has two physical functions and those two functions share the same settings.
Parse the Endpoint node under DSP3 instead of parsing both functions. The
existing parsing logic also has one OOB issue as parsing both functions
will result in accessing past the tc9563_pwrctrl->cfg array. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Add DIRECT_MAP_PHYSMEM_END definition
get_free_mem_region() and mhp_get_pluggable_range() bound their search
to DIRECT_MAP_PHYSMEM_END. LoongArch does not define it, so the fallback
in include/linux/mm.h applies: under CONFIG_SPARSEMEM_VMEMMAP it is
(1ULL << MAX_PHYSMEM_BITS) - 1, a compile-time constant that does not
adapt to the CPU's physical address space bits (cpu_pabits, probed from
CPUCFG1).
The vmemmap window only covers physical space below 2^(cpu_pabits+1)
(i.e. VMEMMAP_SIZE), so on CPUs with fewer physical address bits than
MAX_PHYSMEM_BITS the fallback allows get_free_mem_region() to return
a ZONE_DEVICE region outside the vmemmap window; vmemmap_populate() then
wraps the memmap range around and maps it into low memory, silently
corrupting the page tables. The same search also picked the top-of-
address-space region that crashed memmap_init_zone_device() with amdkfd
on Loongson-3C6000 in 6.16 [1]; the commit 2969b42c8f99 ("LoongArch/mm:
align vmemmap to maximal folio size") keeps that region in bounds on
current Loongson-3C6000 configs, but CPUs with smaller cpu_pabits (e.g.
the Loongson-2K series) are still affected.
Define DIRECT_MAP_PHYSMEM_END as the vmemmap-covered physical range,
(1ULL << (cpu_pabits + 1)) - 1, capped at (1ULL << MAX_PHYSMEM_BITS) - 1
under CONFIG_SPARSEMEM, similar to the commit f3336b48cf9d ("riscv: mm:
Define DIRECT_MAP_PHYSMEM_END").
[1] https://lore.kernel.org/amd-gfx/20250814032153.227285-1-jeffbai@aosc.io/ |
| In the Linux kernel, the following vulnerability has been resolved:
net: au1000: move free_irq out of the close-time spinlocked section
au1000_close() calls free_irq() while aup->lock is still held with
spin_lock_irqsave(). free_irq() can sleep because it takes the IRQ
descriptor request mutex, so it does not belong inside the close-time
spinlocked section.
This was found by our static analysis tool and then confirmed by manual
review of the in-tree au1000_close() .ndo_stop path. The reviewed path
keeps aup->lock held across the MAC reset, queue stop and
free_irq(dev->irq, dev).
A directed runtime validation kept that ndo_stop carrier and the same
free_irq(dev->irq, dev) operation under the driver lock. Lockdep reported
"BUG: sleeping function called from invalid context" and "Invalid wait
context" while free_irq() was taking desc->request_mutex, with
au1000_close() and free_irq() on the stack.
Drop aup->lock before freeing the IRQ. The protected close-time work still
stops the device and queue before IRQ teardown, but the sleepable IRQ core
path now runs outside the spinlocked section. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: mediatek: Protect root bus removal with rescan lock
Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs. Such races may lead to use-after-free issues or system crashes.
[bhelgaas: commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: rockchip: Protect root bus removal with rescan lock
Hold the pci_rescan_remove_lock lock while stopping and removing a root bus
to avoid racing with concurrent rescan or hotplug operations triggered via
sysfs. Such races may lead to use-after-free issues or system crashes.
[bhelgaas: commit log] |
| An out-of-bounds read in libXi's XI2 class parsing via size_classes() and copy_classes() in libXi before 1.8.4 could be used by malicous servers to crash the X client. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: Add NULL check for spi_get_device_id() in spi_get_device_match_data()
Prevent NULL pointer dereference when spi_get_device_id() returns NULL,
which can happen when using driver_override without matching SPI ID entry. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt
rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing
hardware registers, but ignores its return value.
If the runtime resume fails, the function continues to perform register
accesses while the device state is undefined.
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and
return early on failure to avoid unpowered register accesses. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: balance: fix potential bg lookup failure in btrfs_may_alloc_data_chunk()
[BUG]
Running btrfs balance can trigger a null-ptr-deref before relocating a
data chunk when metadata corruption leaves a chunk in the chunk tree
without a corresponding block group in the in-memory cache:
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]
RIP: 0010:btrfs_may_alloc_data_chunk+0x40/0x1c0 fs/btrfs/volumes.c:3601
Call Trace:
__btrfs_balance fs/btrfs/volumes.c:4217 [inline]
btrfs_balance+0x2516/0x42b0 fs/btrfs/volumes.c:4604
btrfs_ioctl_balance fs/btrfs/ioctl.c:3577 [inline]
btrfs_ioctl+0x25cf/0x5b90 fs/btrfs/ioctl.c:5313
...
[CAUSE]
__btrfs_balance() iterates the on-disk chunk tree and passes the chunk
logical bytenr to btrfs_may_alloc_data_chunk() before relocating a data
chunk. That helper then queries the in-memory block group cache:
cache = btrfs_lookup_block_group(fs_info, chunk_offset);
chunk_type = cache->flags; /* cache may be NULL */
A corrupt image can contain a chunk item whose matching block group
item is missing, so no block group is ever inserted into the cache. In
that case btrfs_lookup_block_group() returns NULL.
The code only guards this with ASSERT(cache), which becomes a no-op when
CONFIG_BTRFS_ASSERT is disabled. The subsequent dereference of
cache->flags therefore crashes the kernel.
[FIX]
Add a NULL check after btrfs_lookup_block_group() in
btrfs_may_alloc_data_chunk() and print and error message for clarity. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: fix SmartShift bias sysfs store PM refcount on parse error
Return the parse error before acquiring PM access. |
| An out-of-bounds read in libXi's XI2 class parser in libXi before 1.8.4 could be used by malicious X servers to crash an attached X client. |
| An out-of-bounds read in libXi's XI2 XIQueryDevice reply parsing in libXi before 1.8.4 can be used by a malicious X server to crash an attached X client. |
| IBM Concert 1.0.0 through 3.0.0 references or accesses memory after it has been freed. This allows an attacker who can influence program execution or input may exploit this condition to corrupt memory, cause application crashes, or execute arbitrary code. |
| IBM Concert 1.0.0 through 3.0.0 allows an unauthenticated remote attacker can supply specially crafted input that is incorporated into OS commands, resulting in arbitrary command execution on the underlying system. Successful exploitation allows remote code execution with the privileges of the affected application. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: es18xx: check control allocation before private data setup
snd_es18xx_mixer() creates controls with snd_ctl_new1() and then stores
bookkeeping pointers or sets private_free before calling snd_ctl_add().
snd_ctl_new1() can return NULL on allocation failure, so those writes
can dereference a NULL control pointer.
Check the returned control pointers before using them and return -ENOMEM
on allocation failure. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: sja1105: flower: reject cross-chip redirect
dsa_port_from_netdev() may return a valid port from a different switch
chip. Programming another chip's port index into the local hardware
causes redirection to the wrong port, or an out-of-bounds access if the
index exceeds the local chip's port count.
Apply a minimal fix that adds a check to catch this case and adjusts the
extack message. When cls->common.skip_sw is not set, the operation could
instead redirect to the upstream port and let the software or upstream
switch(es) handle the forward, but that is not addressed here. |
| In the Linux kernel, the following vulnerability has been resolved:
net: qrtr: fix node refcount leak on ctrl packet alloc failure
qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a
reference on the returned node. If the subsequent call to
qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the
function returns -ENOMEM without calling qrtr_node_release() to
release the node reference.
Add qrtr_node_release(node) before returning on the allocation failure
path to properly release the reference. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/ftrace: Fix WARNING in __unregister_ftrace_function
perf_ftrace_function_unregister() unconditionally calls
unregister_ftrace_function() without checking whether the ftrace_ops
was ever successfully registered. This triggers a WARN_ON in
__unregister_ftrace_function() when the ops doesn't have
FTRACE_OPS_FL_ENABLED set.
This can happen during perf_event_alloc() error cleanup when
perf_trace_destroy() is called via __free_event() on an event whose
ftrace_ops registration failed or was already torn down by
perf_try_init_event()'s err_destroy path.
The call path is:
perf_event_alloc() error cleanup
-> __free_event()
-> event->destroy() [tp_perf_event_destroy]
-> perf_trace_destroy()
-> perf_trace_event_close()
-> TRACE_REG_PERF_CLOSE
-> perf_ftrace_function_unregister()
-> unregister_ftrace_function()
-> __unregister_ftrace_function()
-> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED))
Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to
unregister. If the ops is not enabled, just free the filter and
return success. |
| In the Linux kernel, the following vulnerability has been resolved:
usbip: vhci_hcd: fix NULL deref in status_show_vhci
platform_get_drvdata() can return NULL if a VHCI host controller's
probe failed (e.g. due to USB bus number exhaustion). status_show_vhci()
checked for a NULL pdev but not for a NULL hcd returned by
platform_get_drvdata(). Passing NULL to hcd_to_vhci_hcd() does not
return NULL - it returns a pointer offset of 0x260, causing a NULL
pointer dereference when that value is subsequently dereferenced.
Add a NULL check on hcd before calling hcd_to_vhci_hcd(). Move
status_show_not_ready() above status_show_vhci() to make it callable
from the new error path without a forward declaration. |
