| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ARM: 9483/1: select HAVE_POSIX_CPU_TIMERS_TASK_WORK
Commit c6e61c06d606 ("ARM: 9463/1: Allow to enable RT") enabled PREEMPT_RT
on ARM but did not select HAVE_POSIX_CPU_TIMERS_TASK_WORK. This leaves
CONFIG_POSIX_CPU_TIMERS_TASK_WORK disabled, so CPU timers expire in hard
IRQ context.
On PREEMPT_RT this makes run_posix_cpu_timers() take the sleeping
sighand->siglock:
BUG: sleeping function called from invalid context at spinlock_rt.c:48
rt_spin_lock from lock_task_sighand
lock_task_sighand from run_posix_cpu_timers
run_posix_cpu_timers from update_process_times
ARM handles TIF_NOTIFY_RESUME on all return-to-user paths, including v7-M.
ARM32 KVM host support was removed by commit 541ad0150ca4 ("arm: Remove
32bit KVM host support"), so the select need not be conditional on KVM.
Select it to defer POSIX CPU timer expiry to task context.
Reproduced with setrlimit(RLIMIT_CPU, ...) and a busy loop. The same path
is used by setitimer(ITIMER_PROF or ITIMER_VIRTUAL) and POSIX CPU timers
created with timer_create(). |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
In the perf enable path, there are missing cases where
cscfg_csdev_disable_active_config() is not called:
- Branch broadcast is selected but not supported by the hardware
- etm4_enable_hw() fails
This can lead to a leak of config_desc->active_cnt.
Fix this by properly calling cscfg_csdev_disable_active_config()
in these error paths. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: unwind state on add_interface failure
When mt76_wcid_alloc() fails, mt7915_add_interface() returned without
clearing the vif_mask/omac_mask bits it had already set, without removing
the firmware dev info added earlier, and without clearing a monitor_vif
pointer to the vif mac80211 is about to free. mac80211 does not call
remove_interface() for a failed add, so the indices and firmware dev
entry leaked permanently and testmode could dereference the stale
monitor_vif. Add a proper error unwind. |
| In the Linux kernel, the following vulnerability has been resolved:
ublk: check import_ubuf() return value
import_ubuf() can fail if the address range (provided by the userspace
ublk server) is outside the allowed user address space. Return that 0
bytes were copied if import_ubuf() fails rather than passing an
uninitialized struct iov_iter to ublk_copy_user_pages(). |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid1: create serial pool adding rdev to array with serialize_policy=1
The following bug has been observed with kernel 7.1.3 after adding a new
rdev to an existing RAID1 array with serialize_policy enabled:
Oops: 0002 [#1]
CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default
RIP: _raw_spin_lock_irqsave+0x27/0x50
CR2: 0000000000004960
Call Trace:
wait_for_serialization+0xb9/0x260 [raid1]
raid1_make_request+0x762/0xaff [raid1]
md_handle_request+0x1c9/0x2e0 [md_mod]
The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY
is set, and wait_for_serialization assumes that rdev->serial is
initialized. Normally this will be the case for arrays that have
the serialize_policy sysfs attribute set to 1.
But when a new rdev is added to an existing array in bind_rdev_to_array(),
the condition at mddev_create_serial_pool() causes creation of rdev->serial
to be skipped. Fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix return status of RMI log page on allocation failure
nvmet_execute_get_log_page_rmi() leaves 'status' holding NVME_SC_SUCCESS
(set by the successful nvmet_req_find_ns() call) when the kzalloc() for
the log buffer fails. It then jumps to the out label and completes the
request with a success status, so the host is told the command succeeded
while no data was transferred.
Initialize 'status' to NVME_SC_INTERNAL, matching the smart log handler,
so an allocation failure is reported as an internal error. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject programs with inlined helpers if JIT is not available
When an architecture (such as LoongArch, ARM64, and RISC-V) implements
bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper
call offset (insn->imm) in bpf_do_misc_fixups(). This is because the
helper is expected to be inlined by the JIT compiler later. Therefore,
insn->imm remains as the raw helper enum ID.
However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
if JIT compilation fails dynamically (e.g., due to OOM), the program
falls back to the BPF interpreter.
When the interpreter executes (__bpf_call_base + insn->imm) with the
unpatched raw ID, it jumps into an invalid address space, triggering
an instruction alignment fault or a kernel panic.
Although these helpers have valid C implementations in the kernel, the
omission of offset rewriting makes runtime interpreter fallback fatal.
Fix this by setting 'prog->jit_required = 1' when helper call rewriting
is skipped for JIT inlining. This ensures that such programs are safely
rejected if JIT is not available, preventing the runtime kernel panic. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix uncore_box ref/unref ordering
In uncore_event_cpu_online(), uncore_box_ref() was called before
uncore_change_context(). uncore_box_ref() gates on box->cpu >= 0,
but box->cpu is still -1 at that point because uncore_change_context()
has not run yet. As a result, the box is never initialized on the
first CPU to come online in a die, leaving it permanently
uninitialized in the single-CPU-per-die case.
Thus, box->refcnt is one count below the true value, and in the CPU
offline path, the box will be torn down on the second-to-last CPU.
In uncore_event_cpu_offline(), uncore_box_unref() was called after
uncore_change_context(), so box->cpu is already -1 when the collector
CPU goes offline, which prevents it from tearing down the box.
Fix by swapping the call order in both paths so that
uncore_box_{ref,unref}() runs at the point where box->cpu reflects
the correct context.
Move allocate_boxes() out of uncore_box_ref() to enable this
reordering. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARNING in bpf_tracing_link_release
The trampoline could be corrupted by the blindly
'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier.
1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became
'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the
trampoline would poke the target prog's nop insn using jmp insn instead
of call insn.
2. Another fexit loaded with the same tail_call_reachable prog target.
'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'.
3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in
'tr->flags', the trampoline will fail to restore the prog's nop insn
using call insn.
[ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98
...
[ 3.428793] bpf_link_free+0x58/0x130
[ 3.429293] bpf_link_release+0x23/0x30
Fix the warning by updating 'tr->flags' with '|=' and lock. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix vmlinux BTF prep race in bpf_get_btf_vmlinux
bpf_get_btf_vmlinux() lazily parses the vmlinux BTF under the
bpf_verifier_lock, but publishes the result through a plain store
and re-checks it through a plain lockless load. Nothing orders
the stores initializing the struct btf inside btf_parse_vmlinux()
against the store publishing the pointer: On a weakly ordered
arch, a concurrent first-time caller taking the lockless fast
path could in principle observe the pointer before the parsed
contents are visible. The mutex_unlock() does not help such a
reader given it only synchronizes with a later acquisition of the
same lock. Thus, publish the pointer with smp_store_release()
and read it on the fast path with smp_load_acquire().
Acquire semantics are needed rather than a dependency-ordered
READ_ONCE(): btf_parse_vmlinux() also populates globals outside
the returned object (e.g. bpf_ctx_convert.t). An address
dependency would only order accesses performed through the
pointer and not cover other globals. |
| In the Linux kernel, the following vulnerability has been resolved:
misc: bcm-vk: Use acquire/release for msgq_inited
bcm_vk_sync_msgq() fills the message queue information and then sets
msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the
message queues and their cached queue information.
atomic_set()/atomic_read() do not order those accesses. A reader can see
msgq_inited set while still seeing stale queue information. Use release
when publishing the initialized queues and acquire when checking the gate.
Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the
gate and does not publish queue state to readers. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: core: Avoid possible memory reclaim deadlock in TX EQTR context
TX EQTR may run while devfreq gear scaling has quiesced the UFS
tagset. In that context, functions ufshcd_tx_eqtr(), __ufshcd_tx_eqtr()
and ufs_qcom_get_rx_fom() allocate memory with GFP_KERNEL. If direct
reclaim is triggered, reclaim/writeback can depend on I/O to UFS
device. Because the queue is quiesced, this can cause deadlock.
Use memalloc_noio_save/restore() in ufshcd_tx_eqtr() to cover all
allocations in the TX EQTR call tree, including:
- params->eqtr_record in ufshcd_tx_eqtr()
- eqtr_data in __ufshcd_tx_eqtr()
- params in ufs_qcom_get_rx_fom()
This is preferred over tagging individual call sites with GFP_NOIO, as it
automatically covers any future allocations added anywhere in the call tree
without requiring each caller to be aware of this constraint.
[mkp: fix label as suggested by Bart] |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: keembay - Fix AEAD unregister count in error path
register_aes_algs() registers the AEAD algorithms before registering the
skcipher algorithms. If skcipher registration fails, the function unwinds
the earlier AEAD registration with crypto_engine_unregister_aeads(), but it
passes ARRAY_SIZE(algs), which is the skcipher table size.
Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper
iterates over the same table that was registered. Also clarify the nearby
comment: the crypto registration helpers clean up algorithms registered
within the same call, while this function must still unwind earlier
successful registration steps. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Clean up channels on setup failure
scmi_channels_setup() can fail after the common BASE channel or earlier
protocol channels have already been registered in the TX/RX IDRs.
Route this failure through the existing channel cleanup label so the
transport channels, transport devices and IDR state created before the
failure are released before the probe error path frees the SCMI instance
ID. |
| In the Linux kernel, the following vulnerability has been resolved:
leds: lp5860: Fix a potential double-unlock
In lp5860_device_init(), if lp5860_init_dt() fails, an already unlocked
mutex is unlocked another time.
Slightly rework how the lock is taken/released to avoid this potential
double unlock. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: camcc-sc8280xp: unregister CAMCC_GDSC_CLK
With the introduction of sync_state support in the clk and pmdomain
subsystems, the following warning happens when the unused clocks are
shutdown in camcc-sc8280xp:
[ 15.408367] titan_top_gdsc status stuck at 'on'
[ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14
[ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common
snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro
bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops
qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev
snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram
lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator
[ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec
qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux
qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan
dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock
pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl
smem hid_multitouch fuse i2c_dev
[ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy)
[ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024
[ 15.408942] Workqueue: pm pm_runtime_work
[ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160
[ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160
[ 15.408987] sp : ffff8000800f3b40
[ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000
[ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88
[ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd
[ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002
[ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101
[ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc
[ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001
[ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000
[ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000
[ 15.409098] Call trace:
[ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P)
[ 15.409115] gdsc_disable+0x4c/0x190
[ 15.409126] _genp
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/lima: call drm_mm_init() with a valid allocation range
lima_vm_create() is currently run before va_start and va_end are set up,
meaning they are both 0. lima_vm_create() runs drm_mm_init() with them
as arguments for the allocator, and if DRM_DEBUG_MM is enabled the
DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on
exynos4412-odroid-u2:
[ 1.736297] ------------[ cut here ]------------
[ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931!
[ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 1.750697] Modules linked in:
[ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT
[ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree)
[ 1.769446] Workqueue: events_unbound deferred_probe_work_func
[ 1.775261] PC is at drm_mm_init+0x9c/0xa4
[ 1.779339] LR is at lima_vm_create+0x144/0x17c
[ ... ]
Fix the issue by moving the lima_vm_create() call after va_start and
va_end are set up. |
| In the Linux kernel, the following vulnerability has been resolved:
udf: Mark LVID buffer as uptodate before marking it dirty
When an I/O error occurs while writing the Logical Volume Integrity
Descriptor (LVID) buffer to the block device, the block layer's completion
handler (`end_buffer_write_sync()`) clears the `BH_Uptodate` flag on the
buffer. However, the buffer still contains valid LVID data in memory. If
the filesystem is subsequently remounted read-write or synced,
`udf_open_lvid()` or `udf_sync_fs()` will modify the LVID buffer and call
`mark_buffer_dirty()`. This triggers a spurious
`WARN_ON_ONCE(!buffer_uptodate(bh))` warning in `mark_buffer_dirty()`
because the buffer is not marked uptodate, even though its in-memory
contents are valid and are about to be overwritten.
To prevent this spurious warning, unconditionally set the `BH_Uptodate`
flag before calling `mark_buffer_dirty()` in `udf_open_lvid()` and
`udf_sync_fs()`. This acknowledges that the in-memory buffer is valid and
matches the workaround previously applied to `udf_close_lvid()` in commit
853a0c25baf9 ("udf: Mark LVID buffer as uptodate before marking it dirty").
Extending this workaround ensures consistent behavior across all LVID
updates.
Buffer I/O error on dev loop0, logical block 128, lost sync page write
------------[ cut here ]------------
!buffer_uptodate(bh)
WARNING: fs/buffer.c:1087 at mark_buffer_dirty+0x299/0x410 fs/buffer.c:1087
...
Call Trace:
<TASK>
udf_open_lvid+0x369/0x5b0 fs/udf/super.c:2078
udf_reconfigure+0x336/0x540 fs/udf/super.c:679
reconfigure_super+0x232/0x8f0 fs/super.c:1080
vfs_cmd_reconfigure fs/fsopen.c:268 [inline]
vfs_fsconfig_locked+0x171/0x320 fs/fsopen.c:297
__do_sys_fsconfig fs/fsopen.c:463 [inline]
__se_sys_fsconfig+0x6b9/0x810 fs/fsopen.c:350
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
bpf,lsm: Drop bpf_prog_free from sleepable_lsm_hooks
__bpf_prog_put_rcu() is the call_rcu() callback for non-sleepable programs.
security_bpf_prog_free() called from there fires bpf_prog_free in softirq;
if a sleepable LSM prog is attached to that hook, might_fault() BUGs:
BUG: sleeping function called from invalid context
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5038
preempt_count: 101, expected: 0
Call Trace:
<IRQ>
__bpf_prog_enter_sleepable+0x1cd/0x320 kernel/bpf/trampoline.c:1255
bpf_trampoline_6442549705+0x53/0xd7
security_bpf_prog_free+0xde/0x130 security/security.c:5465
__bpf_prog_put_rcu+0xab/0xd0 kernel/bpf/syscall.c:2365
rcu_do_batch kernel/rcu/tree.c:2617 [inline]
handle_softirqs+0x236/0x800 kernel/softirq.c:622
</IRQ>
The call_rcu/call_rcu_tasks_trace split reflects the freed program's
sleepability, not that of any attached observer.
security_bpf_prog_free() also frees prog->aux->security, which has to stay
after the grace period, so drop bpf_prog_free from sleepable_lsm_hooks
rather than move the call. Non-sleepable observers still run there. |
| In the Linux kernel, the following vulnerability has been resolved:
dm-pcache: validate the persisted dirty_tail chain at load
The writeback worker follows the persisted dirty_tail chain, which is
decoded from the cache device independently of the key_tail chain that
cache_replay() walks and bounds. A crafted image, whose on-media fields are
authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a
chain of last ksets that never terminates, so cache_writeback_fn() re-arms
itself with no delay forever.
Walk the dirty_tail chain once at load with the same hop cap cache_replay()
uses and fail the table load with -EIO if it does not reach an end within
n_segs hops. |
