| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for disabled VBUS regulator
devm_regulator_get_exclusive() initialises the regulator with
enable_count = 1, requiring the consumer to disable it before release.
The devm disable action was previously only registered when the caller
explicitly requested enable, so when the regulator was left in its initial
enabled state without an explicit enable call, the cleanup path skipped
decrementing enable_count, triggering a WARN_ON during regulator
release on device removal.
Fix this by always registering the devm disable action based on the actual
enabled state via regulator_is_enabled(), regardless of whether the
caller requested an explicit enable. This covers both the explicitly
enabled case and the initial state set by devm_regulator_get_exclusive(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate
ath11k can receive HT/VHT/HE frames whose reported MCS is above the
maximum that can be expressed in the corresponding mac80211 rate space
(e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11).
The frame itself is valid and decodes correctly, but for such a frame
ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range
value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY
from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches
mac80211 it trips the rate sanity check and the frame is dropped with a
splat:
ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12
WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211]
Dropping the frame would discard otherwise valid data, so instead cap the
reported MCS to the maximum the rate space can express and deliver the
frame. Set rx_status->encoding before the range check and assign rate_idx
from the capped value, so a frame with an out-of-range MCS no longer
leaves partial or bogus rate metadata behind. Also downgrade the logging
level since they are not treated as invalid frames now. The only loss is
that such a frame is reported as the capped MCS in the rx rate statistics.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix circular lock dependency in ext4_ext_migrate
Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a
circular lock dependency between s_writepages_rwsem and sb_internal
(freeze protection).
The deadlock scenario:
CPU0 (EXT4_IOC_MIGRATE) CPU1 (orphan cleanup during mount)
---- ----
ext4_ext_migrate()
ext4_writepages_down_write()
s_writepages_rwsem (write)
ext4_evict_inode()
sb_start_intwrite() [sb_internal]
...
ext4_writepages()
s_writepages_rwsem (read) [BLOCKED]
iput(tmp_inode)
ext4_evict_inode()
sb_start_intwrite() [BLOCKED]
The tmp_inode is a temporary inode with nlink=0 created solely for
building the extent tree. Its eviction does not require
s_writepages_rwsem protection, so deferring iput() until after
releasing the rwsem is safe. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: skip extra isize expansion during mount to prevent deadlock
ext4_try_to_expand_extra_isize() is called from __ext4_mark_inode_dirty()
while holding an active jbd2 handle. During mount (!SB_ACTIVE), the
expand path may move xattrs to external blocks and release ea_inodes via
iput(). When !SB_ACTIVE, iput() calls write_inode_now() which acquires
s_writepages_rwsem, creating a circular lock dependency:
s_writepages_rwsem --> jbd2_handle --> xattr_sem --> s_writepages_rwsem
This can be triggered via:
ext4_process_orphan() -> ext4_truncate() -> ext4_mark_inode_dirty()
-> ext4_try_to_expand_extra_isize()
or:
ext4_evict_inode() -> ext4_mark_inode_dirty()
-> ext4_try_to_expand_extra_isize()
Skip expansion when !SB_ACTIVE. This is a minor loss of functionality
(extra isize won't grow for these inodes during mount), which e2fsck
can resolve later if needed. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: RSI: fix field-spanning write warning in attestation token init
The challenge is passed in registers a1 through a8. However, copying to
®s.a1 makes FORTIFY treat the destination as the single a1 field,
resulting in a field-spanning write warning. [1]
Overlay the SMCCC register structure with an RSI-specific argument
layout and copy the challenge into an explicit 64-byte array. This keeps
the existing a1-a8 argument encoding while giving the copy a correctly
sized destination object.
[1]
memcpy: detected field-spanning write (size 64) of single field "®s.a1" at ./arch/arm64/include/asm/rsi_cmds.h:119 (size 8)
WARNING: ./arch/arm64/include/asm/rsi_cmds.h:119 at rsi_attestation_token_init+0xdc/0xf8 [arm_cca_guest], CPU#0: cat/3314 |
| In the Linux kernel, the following vulnerability has been resolved:
clk: eswin: Zero-initialize stack-allocated clk_init_data
eswin_clk_register_pll() and eswin_register_clkdiv() declare a struct
clk_init_data on the stack and only initialize some of its fields
(parent_data respectively parent_hws). clk_core_populate_parent_map()
checks parent_names first and parent_data second before falling back
to parent_hws, so leftover stack garbage in the uninitialized fields
hijacks parent resolution and the clk core dereferences a bogus
pointer:
Unable to handle kernel NULL pointer dereference at virtual address 000000000000000c
Oops [#1]
epc : __clk_register+0x31a/0x7f0
[<ffffffff805dc774>] __clk_register+0x31a/0x7f0
[<ffffffff805dcd76>] devm_clk_hw_register+0x2a/0x94
[<ffffffff805e319a>] eswin_register_clkdiv+0x80/0xd0
[<ffffffff805e34a0>] eswin_clk_register_clks+0x162/0x1a0
[<ffffffff805e3736>] eic7700_clk_probe+0x146/0x180
[<ffffffff8065d23c>] platform_probe+0x3c/0x7a
Observed on EIC7700 hardware (with the driver backported to a 6.17
tree); whether the bug triggers depends entirely on what the stack
happens to contain when the registration helpers run.
Zero-initialize both structures. |
| minimp3 commit ea99364f contains an integer overflow vulnerability in mp3dec_skip_id3v1() when parsing the APEv2 tag-size field. |
| In getManageSpaceActivityIntent of StorageManagerService.java, there is a possible LaunchAnyWhere chain due to an unsafe PendingIntent. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation. |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1189. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: hibernate: mask DAIF before restoring hibernated kernel
The arm64 hibernate code manages the exception masking in an unsound
way, leading to potential crashes and/or warnings during resume.
When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF
exceptions are masked (by virtue of `local_daif_save()`), and the
suspended image is saved assuming that all DAIF exceptions will remain
masked when the image is restored.
When a hibernation image is resumed by `swsusp_arch_resume()`, only
interrupts are masked (by virtue of `local_irq_disable()` in
`resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits
will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be
clear.
This means that there are two problems:
(1) It is possible to take Debug, SError, or pseudo-NMI exceptions
during the resume process. This is unsafe, as during the resume
process both the old ane new kernels will tranisently be in an
inconsistent state, and swsusp_arch_suspend_exit() won't retain
an executable mapping of any exception vectors.
Any exception taken here will be fatal and silent.
(2) When re-entering the resumed kernel, some DAIF bits will be clear
unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions
to be taken for a short period while the resumed kernel is not yet
in a consistent state.
This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING.
Avoid these issues by masking all DAIF exceptions during resume. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: make sure EXTENT_BUFFER_READING is cleared under refs_lock
[FALSE ALERTS]
There is a bug report that the warning inside
invalidate_and_check_btree_folios() got triggered during btrfs/298:
BTRFS info (device sdd): first mount of filesystem f9bf732a-a19b-44b9-99a7-614ddff168e2
BTRFS info (device sdd): using crc32c checksum algorithm
BTRFS error (device sdd): failed to find fsid cb2fdb42-b638-4f2f-badd-4127467ba674 when attempting to open seed devices
BTRFS error (device sdd): failed to read chunk tree: -2
------------[ cut here ]------------
WARNING: disk-io.c:3342 at invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs], CPU#4: mount/125993
CPU: 4 UID: 0 PID: 125993 Comm: mount Tainted: G W OE 7.1.0-rc7-custom+ #1 PREEMPT(full)
Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025
Call trace:
invalidate_and_check_btree_folios+0x260/0x3c0 [btrfs] (P)
open_ctree+0x1f50/0x23b0 [btrfs]
btrfs_get_tree+0x89c/0xc48 [btrfs]
vfs_get_tree+0x30/0x110
vfs_cmd_create+0x58/0xe8
__arm64_sys_fsconfig+0x39c/0x518
invoke_syscall.constprop.0+0x48/0x120
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x24/0x38
el0_svc+0x50/0x310
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x198/0x1a0
---[ end trace 0000000000000000 ]---
BTRFS warning (device sdd): unable to release extent buffer 365985792 owner 3 gen 17 refs 3 flags 0x5
[CAUSE]
In that invalidate_and_check_btree_folios() we wait for the eb to finish
its read, then check if it's only held by us and the btree inode.
If not, then do a warning as it may be still held, and could cause
problems.
But there is a small window where the check can lead to false alerts:
Thread A (Read endio) | Thread B (Unmount)
----------------------------------+-------------------------------------
end_bbio_meta_read() |
| The eb has one extra ref held |
| by the reader, and has |
| EXTENT_BUFFER_READING flag set | invalidate_and_check_btree_folios()
| | |
|- clear_extent_buffer_reading() | |
| | |- wait_on_bit_io();
| | | The EXTENT_BUFFER_READING flag is
| | | cleared
| | |- if (refcount_read(eb->refs) > 2)
| | The eb is held by the read, us
| | and btree inode, thus it
| | will trigger the warning
|- free_extent_buffer() |
[FIX]
Introduce a helper, free_extent_buffer_clear_reading().
If the new parameter, @clear_reading, is set, we will hold the spinlock
at the beginning of free_extent_buffer_clear_reading() to make sure the
EXTENT_BUFFER_READING flag is cleared inside the same critical section
of decreasing refs.
Now free_extent_buffer() will just call
free_extent_buffer_clear_reading() with @clear_reading set to false, so
no behavior change.
But for end_bbio_meta_read(), it will not clear_extent_buffer_reading()
directly, but pass @clear_reading as true.
Then inside invalidate_and_check_btree_folios(), hold the refs_lock
before reading refs.
So that we eliminate the race window completely. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit
Currently, when exiting to kernel mode, we attempt involuntary
preemption. The preemption logic expects IRQs to be disabled, which is
why we call local_irq_disable() before attempting preemption.
However, depending on the context, local_irq_disable() may be
unnecessary:
- __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so
local_irq_disable() is redundant.
- irqentry_exit_to_kernel_mode_preempt() immediately returns when
exiting from an NMI-like context, so calling local_irq_disable()
beforehand is unnecessary work.
Furthermore, it confuses the pNMI state tracking when we are in a
context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set
in the PMR, leading to a warning when
CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y:
WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805
CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY
pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--)
pc : arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63)
lr : el1_abort (arch/arm64/kernel/entry-common.c:323)
pmr: 000000f0
Call trace:
arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) (P)
el1_abort (arch/arm64/kernel/entry-common.c:323)
el1h_64_sync_handler (arch/arm64/kernel/entry-common.c:449)
el1h_64_sync (arch/arm64/kernel/entry.S:589)
[...]
Split arm64_exit_to_kernel_mode() into preempt, non-preempt, and
dispatch parts so that we can avoid this extra work where it is not
needed and avoid breaking the pNMI tracking logic. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: bus: Introduce acpi_bus_get_primary_device()
The function used for obtaining the first "physical" device for which
the given ACPI one is the ACPI companion, acpi_get_first_physical_node(),
may return a stale device pointer (mostly in theory) because
acpi_unbind_one() may run as a whole after dropping the ACPI device's
physical_node_lock in acpi_get_first_physical_node() and before it
returns. The last reference to the "physical" device may be dropped
then before the pointer to it is returned to the caller.
If that happens and the acpi_get_first_physical_node() caller invokes
get_device() on the pointer obtained from it, which is done by the
majority of its callers, a use-after-free will occur.
To prepare for addressing this problem, introduce a new function for
getting the first "physical" device associated with the given ACPI one
(the "primary physical device") that will also reference count the
device in question before returning a pointer to it.
Make that new function and acpi_get_first_physical_node() share the
physical node list lookup code.
No intentional functional impact. |
| In get_eht_operation_channel_width of ieee802_11_common.c, there is a possible out of bounds read due to an incorrect bounds check. This could lead to remote (proximal/adjacent) information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple functions, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In tt_face_colr_blend_layer of ttcolr.c, there is a possible remote code execution due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In multiple locations, there is a possible memory safety issue due to a heap buffer overflow. This could lead to remote code execution with no additional execution privileges needed. User interaction is not needed for exploitation. |
| Termix is a web-based server management platform with SSH terminal, tunneling, and file editing capabilities. From 2.5.0 until 2.5.1, Termix allows authenticated users to configure webhook or ntfy notification channels with attacker-controlled destination URLs and trigger server-side requests through the notification-channel test endpoint. The request path in src/backend/database/routes/alert-rules-routes.ts reaches src/backend/utils/notification-sender.ts without destination allowlisting or private-address blocking. This permits blind requests to internal HTTP services reachable by the Termix server. Webhook mode also permits attacker-controlled HTTP methods and headers, which can cause limited state changes when an internal service accepts the fixed notification body, although response bodies are not returned. This issue is fixed in version 2.5.1. |
| In multiple locations, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
| In parseParts of PduParser.java, there is a possible out of bounds read due to a heap buffer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. |
