| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix OOB in scmi_power_name_get()
scmi_power_name_get() does not validate the domain number passed by the
external caller, which may lead to an out-of-bounds access.
Fix this by returning "unknown" for invalid domains, like
scmi_reset_name_get() does. |
| In the Linux kernel, the following vulnerability has been resolved:
pinctrl: spacemit: fix NULL check in spacemit_pin_set_config
spacemit_pin_set_config() looks up the per-pin descriptor with
spacemit_get_pin() then checks the wrong variable for failure:
const struct spacemit_pin *spin = spacemit_get_pin(pctrl, pin);
...
if (!pin)
return -EINVAL;
reg = spacemit_pin_to_reg(pctrl, spin->pin);
pin is an unsigned int pin id, where 0 (GPIO_0 / gmac0_rxdv on K3) is a
valid pin, so rejecting it here drops the PAD config write for the first
pin of every group. On K3 Pico-ITX the GMAC RGMII group lists pin 0 as
its first entry, so its drive-strength / bias configuration was silently
ignored.
The intended guard is against spacemit_get_pin() returning NULL when the
pin id isn't in the SoC's pin table. Check spin instead, which both
restores PAD setup for pin 0 and prevents a NULL deref on spin->pin. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: guard against possible NULL deref in __in6_dev_stats_get()
dev_get_by_index_rcu() could return NULL if the original physical
device is unregistered.
Found by Sashiko. |
| In the Linux kernel, the following vulnerability has been resolved:
rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()
With a list_for_each() loop, if we don't find the item we are looking for
in the list, then the loop exits with the iterator, which is "dbell" in
this loop, pointing to invalid memory.
This code uses the "found" variable to determine if we have found the
doorbell we are looking for or not. However, the problem that the "found"
variable needs to be set to false at the start of each iteration,
otherwise after the first correct doorbell, then everything is marked as
found.
Reset the "found" to false at the start of the iteration and move the
variable inside the loop. |
| In the Linux kernel, the following vulnerability has been resolved:
EDAC/igen6: Fix call trace due to missing release()
When unloading the igen6_edac driver, there is a call trace:
Device '(null)' does not have a release() function, it is broken and must be fixed.
See Documentation/core-api/kobject.rst.
WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209
...
RIP: 0010:device_release+0x84/0x90
Call Trace:
<TASK>
kobject_put+0x8c/0x220
put_device+0x17/0x30
igen6_unregister_mcis+0xa2/0xe0 [igen6_edac]
igen6_remove+0x82/0xb0 [igen6_edac]
...
Fix the call trace by providing empty release() functions for the
memory controller devices. |
| In the Linux kernel, the following vulnerability has been resolved:
liveupdate: Reference count incoming FLB data
Increment the incoming FLB refcount in liveupdate_flb_get_incoming() so
that the FLB structure cannot be freed while the caller is actively using
it. Add an additional liveupdate_flb_put_incoming() function so the
caller can explicitly indicate when it is done using the FLB data.
During a Live Update, a subsystem might need to hold onto the incoming
File-Lifecycle-Bound (FLB) data for an extended period, such as during
device enumeration. Incrementing the reference count guarantees that the
data remains valid and accessible until the subsystem releases it,
preventing future use-after-free bugs. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: wlcore: enable the right set of ciphers
The firmware version number check for IGTK introduced in
commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key")
lets the amount of ciphers decrease on every boot of a too old firmware and
that is practically happening. It also does not take into account other
chips than the wl18xx. On some wl128x, the following can be observed
when connecting via nm to a common ap:
[ 484.113311] wlcore: WARNING could not set keys
[ 484.117828] wlcore: ERROR Could not add or replace key
[ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5)
[ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142
[ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1
[ 484.145721] wlcore: down
[ 484.148986] ieee80211 phy0: Hardware restart was requested
[ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142)
[ 484.633758] wlcore: Association completed.
[ 484.690490] wlcore: ERROR command execute failure 14
[ 484.690490] ------------[ cut here ]------------
[ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892
This repeats endlessly.
Always disable IGTK on wl12xx and fix the decrementing mess. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/fwctl: Fix __fortify_panic
Fix a runtime assertion in cxlctl_get_supported_features(). Fortify
complains that it is potentially overflowing the entries array per
__counted_by_le(num_entries). Quiet the false positive by initializing
@num_entries earlier.
memcpy: detected buffer overflow: 48 byte write of buffer size 0
WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398
RIP: 0010:__fortify_report+0x50/0xa0
Call Trace:
__fortify_panic+0xd/0xf
cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core] |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/test: Fix __fortify_panic
Fix a runtime assertion in setup_xor_mapping(). Fortify complains that it
is potentially overflowing the xormaps array per __counted_by(nr_maps).
Quiet the false positive by initializing @nr_maps earlier.
memcpy: detected buffer overflow: 32 byte write of buffer size 0
WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#8: modprobe/2728
Call Trace:
__fortify_panic+0xd/0xf
setup_xor_mapping+0x6c/0xa0 [cxl_translate]
[ dj: Fixed up @nr_entries to @nr_maps in commit log. ] |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: fix unaligned memory access in timestamp adjustment
Use get_unaligned_be32() and put_unaligned_be32() to safely read and
write the timestamp fields. This prevents performance degradation due to
unaligned memory access or even a crash on strict alignment
architectures.
This follows the implementation of timestamp parsing in the networking
stack at tcp_parse_options() and synproxy_parse_options(). |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag
The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps
inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the
decrement still happens and wraps it to 255. The break only leaves
the inner switch -- a later path entry can set info->indev back to
a real device, and we end up returning with num_encaps == 255.
nft_dev_forward_path() then walks info.encap[] (size 2) up to
num_encaps, which means an OOB stack read and a bogus count copied
into the route descriptor.
Should only happen on a malformed bridge path stack, hence the WARN,
but worth handling sanely. Move the decrement out of the WARN.
[ While at this, remove the WARN_ON_ONCE since this can only happen
with a buggy bridge path stack --pablo ]. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: Fix NULL pointer dereference in mt7996_init_tx_queues()
When MT76_NPU and CONFIG_NET_MEDIATEK_SOC_WED are enabled and
mt76 detects properly the Airoha NPU SoC, mt7996_init_tx_queues() will
dereference a NULL WED pointer.
Fix the issue by always passing the WED pointer from mt7996_dma_init(). |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: lzo: reject compressed segment that overflows the compressed input
lzo_decompress_bio() validates each on-disk segment length seg_len only
against the workspace cbuf size, not against the compressed input size
(compressed_len, the total folio bytes of the bio). A crafted extent can
carry a segment whose seg_len passes the cbuf check but runs past the end
of the bio, so copy_compressed_segment() walks off the last folio:
get_current_folio() then returns the NULL folio from bio_next_folio(), and
with CONFIG_BTRFS_ASSERT disabled (default) folio_size(NULL) faults.
BUG: KASAN: null-ptr-deref in lzo_decompress_bio (fs/btrfs/lzo.c:383)
Read of size 8 at addr 0000000000000000 by task kworker/u8:1/29
Workqueue: btrfs-endio simple_end_io_work
kasan_report (mm/kasan/report.c:590)
lzo_decompress_bio (fs/btrfs/lzo.c:383)
end_bbio_compressed_read (fs/btrfs/compression.c:1065)
btrfs_bio_end_io (fs/btrfs/bio.c:135)
btrfs_check_read_bio (fs/btrfs/bio.c:180 fs/btrfs/bio.c:285)
simple_end_io_work
process_one_work
worker_thread
Reject any segment whose payload would extend beyond compressed_len before
copying it, treating it as corruption like the other on-disk validation
failures in this function. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: npc: Fix size of entry2cntr_map
KASAN prints below splat. This is caused by allocating counter for
reserved mcam entry for cpt 2nd pass entry. But mcam->entry2cntr_map
is not allocated for reserved entries.
BUG: KASAN: slab-out-of-bounds in npc_map_mcam_entry_and_cntr+0xb0/0x1a0
Write of size 2 at addr ffff0001033e7ffe by task kworker/0:1/14
CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.1.67 #1
Hardware name: Marvell CN106XX board (DT)
Workqueue: events work_for_cpu_fn
Call trace:
dump_backtrace.part.0+0xe4/0xf0
show_stack+0x18/0x30
dump_stack_lvl+0x88/0xb4
print_report+0x154/0x458
kasan_report+0xb8/0x194
__asan_store2+0x7c/0xa0
npc_map_mcam_entry_and_cntr+0xb0/0x1a0
rvu_mbox_handler_npc_mcam_write_entry+0x268/0x280
npc_install_flow+0x840/0xfe0
rvu_npc_install_cpt_pass2_entry+0x138/0x190
rvu_nix_init+0x148c/0x2880
rvu_probe+0x1800/0x30b0
local_pci_probe+0x78/0xe0
work_for_cpu_fn+0x30/0x50
process_one_work+0x4cc/0x97c
worker_thread+0x360/0x630
kthread+0x1a0/0x1b0
ret_from_fork+0x10/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: oss: Serialize readq reset state with q->lock
snd_seq_oss_readq_clear() resets qlen, head, and tail without
q->lock even though the normal reader and producer paths serialize the
same ring state under that spinlock. A reset can therefore race
snd_seq_oss_readq_free() or snd_seq_oss_readq_put_event() and leave
stale records in the queue, drop freshly queued ones, or report the
wrong readiness after wakeup. KCSAN reports a data race between
snd_seq_oss_readq_clear() and snd_seq_oss_readq_free().
Take q->lock while clearing the ring and resetting input_time. Factor
the enqueue logic into a caller-locked helper so
snd_seq_oss_readq_put_timestamp() updates its suppression state under
the same lock instead of racing the reset path.
The buggy scenario involves two paths, with each column showing the
order within that path:
reset path: locked readq updater:
1. snd_seq_oss_reset() or 1. A reader or callback producer
release reaches takes q->lock on the same queue.
snd_seq_oss_readq_clear().
2. snd_seq_oss_readq_clear() 2. The updater tests or modifies
resets qlen, head, tail, qlen, head, and tail.
and input_time.
3. snd_seq_oss_readq_clear() 3. The updater completes its
wakes sleepers on read-modify-write sequence.
q->midi_sleep.
4. Without q->lock, the reset 4. The resulting ring state drives
can overlap the locked later reads and readiness.
update.
KCSAN reports:
BUG: KCSAN: data-race in snd_seq_oss_readq_clear /
snd_seq_oss_readq_free
write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0:
snd_seq_oss_readq_free+0x6c/0x80
snd_seq_oss_read+0xcb/0x250
odev_read+0x38/0x60
vfs_read+0xff/0x600
ksys_read+0xb4/0x140
__x64_sys_read+0x46/0x60
do_syscall_64+0xbb/0x2f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1:
snd_seq_oss_readq_clear+0x1f/0x90
snd_seq_oss_reset+0xa7/0xf0
snd_seq_oss_ioctl+0x6f6/0x7e0
odev_ioctl+0x56/0xc0
__x64_sys_ioctl+0xd1/0x120
do_syscall_64+0xbb/0x2f0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000 |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del
fsl_emb_pmu_del() unconditionally calls put_cpu_var(cpu_hw_events) at
the 'out:' label, but only calls the matching get_cpu_var() after the
'i < 0' early-return check. When event->hw.idx is negative the
function jumps to 'out:' without having taken get_cpu_var(), and the
trailing put_cpu_var() then issues an unmatched preempt_enable(),
underflowing preempt_count.
On a CONFIG_PREEMPT=y kernel preempt_count would underflow and
eventually present as a 'scheduling while atomic' BUG.
Move put_cpu_var() to pair with get_cpu_var() so the percpu access is
correctly bracketed and the 'out:' label only handles perf_pmu_enable. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix memory leak of bonding resources
In a corner case of concurrent driver removal and driver reset,
bonding resource is first released in hns_roce_hw_v2_exit() during
driver removal, and then is allocated again in hns_roce_register_device()
during driver reset. This leads to memory leak because the release
timing has already passed. This may also lead to a kernel panic
as below because of the leaked notifier callback:
Call trace:
0xffffa20fccc04978 (P)
raw_notifier_call_chain+0x20/0x38
call_netdevice_notifiers_info+0x60/0xb8
netdev_lower_state_changed+0x4c/0xb8
As Sashiko suggested, the teardown order of bonding resources should
be inverted to make sure the resources are released when the driver
is removed. |
| In the Linux kernel, the following vulnerability has been resolved:
mfd: cs42l43: Sanity check firmware size
Currently the code checks if a firmware was received, however it does
not verify that the firmware size is larger than the firmware header. As
the firmware pointer is dereferenced as a pointer to the header
structure this could lead to an out of bounds memory access. Add the
missing check. |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: ete: Always save state on power down
System register ETMs and ETE are unlikely to be preserved on CPU power
down. The ETE DT binding also never documented
"arm,coresight-loses-context-with-cpu" so nobody would have legitimately
been able to use that binding to fix it and ACPI has no such binding at
all.
Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg)
or ACPI boots. Use a local variable when setting up save_state so that
it's immune to concurrent probing when devices have different
configurations which is an issue with modifying the global.
This fixes the following error when using Coresight with ACPI on the FVP
which supports CPU PM:
coresight ete0: External agent took claim tag
WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117 |
| In the Linux kernel, the following vulnerability has been resolved:
char: tlclk: fix use-after-free in tlclk_cleanup()
This patch improves the module cleanup process in the tlclk driver to
prevent potential use-after-free and race conditions.
Currently, the file_operations structure does not specify the .owner
field, which could allow the module to be unloaded while user-space
processes are still interacting with the device. Additionally, the
tlclk_cleanup() function frees the alarm_events memory before ensuring
that blocked processes in the waitqueue are fully awakened and that the
switchover_timer has completed.
To address these cases, this patch:
- Sets '.owner = THIS_MODULE' in tlclk_fops to safely defer module
unloading while the device is in use.
- Updates tlclk_cleanup() to explicitly wake up all blocked readers
(wake_up_all), properly release hardware I/O regions, and safely
delete the timer (timer_delete_sync) prior to freeing memory. |
