| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
srcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL
Commit 994f706872e6 ("srcu: Make Tree SRCU able to operate without
snp_node array") assumes that cpu 0 is always online. However, there
really are situations when some other CPU is the boot CPU, for example,
when booting a kdump kernel with the maxcpus=1 boot parameter.
On PowerPC, the kdump kernel can hang as follows:
...
[ 1.740036] systemd[1]: Hostname set to <xyz.com>
[ 243.686240] INFO: task systemd:1 blocked for more than 122 seconds.
[ 243.686264] Not tainted 6.1.0-rc1 #1
[ 243.686272] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000
[ 243.686296] Call Trace:
[ 243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable)
[ 243.686317] [c000000016657830] [c00000001001dec0] __switch_to+0x130/0x220
[ 243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580
[ 243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140
[ 243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+0x168/0x1c0
[ 243.686374] [c000000016657a80] [c000000010f61de8] __wait_for_common+0x148/0x360
[ 243.686387] [c000000016657b20] [c000000010176bb0] __flush_work.isra.0+0x1c0/0x3d0
[ 243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40
[ 243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160
[ 243.686428] [c000000016657c40] [c0000000105f6500] inotify_release+0x30/0xa0
[ 243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350
[ 243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170
[ 243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140
[ 243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270
[ 243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180
[ 243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280
[ 243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4
[ 243.686528] NIP: 00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000
[ 243.686538] REGS: c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1)
[ 243.686548] MSR: 800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE> CR: 42044440 XER: 00000000
[ 243.686572] IRQMASK: 0
[ 243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000
[ 243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001
[ 243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000
[ 243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000
[ 243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 243.686572] GPR20: 0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000
[ 243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570
[ 243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98
[ 243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4
[ 243.686691] LR [0000000000000000] 0x0
[ 243.686698] --- interrupt: 3000
[ 243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds.
[ 243.686717] Not tainted 6.1.0-rc1 #1
[ 243.686724] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800
[ 243.686747] Workqueue: events_unbound fsnotify_mark_destroy_workfn
[ 243.686758] Call Trace:
[ 243.686762] [c0000000166736e0] [c00000004fd91000] 0xc00000004fd91000 (unreliable)
[ 243.686775] [c0000000166738d0] [c00000001001dec0] __switch_to+0x130/0x220
[ 243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: output extra debug info if we failed to find an inline backref
[BUG]
Syzbot reported several warning triggered inside
lookup_inline_extent_backref().
[CAUSE]
As usual, the reproducer doesn't reliably trigger locally here, but at
least we know the WARN_ON() is triggered when an inline backref can not
be found, and it can only be triggered when @insert is true. (I.e.
inserting a new inline backref, which means the backref should already
exist)
[ENHANCEMENT]
After the WARN_ON(), dump all the parameters and the extent tree
leaf to help debug. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: wcd938x: fix missing mbhc init error handling
MBHC initialisation can fail so add the missing error handling to avoid
dereferencing an error pointer when later configuring the jack:
Unable to handle kernel paging request at virtual address fffffffffffffff8
pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
Call trace:
wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]
qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]
sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]
snd_soc_link_init+0x28/0x90 [snd_soc_core]
snd_soc_bind_card+0x628/0xbfc [snd_soc_core]
snd_soc_register_card+0xec/0x104 [snd_soc_core]
devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]
sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp] |
| In the Linux kernel, the following vulnerability has been resolved:
md: don't dereference mddev after export_rdev()
Except for initial reference, mddev->kobject is referenced by
rdev->kobject, and if the last rdev is freed, there is no guarantee that
mddev is still valid. Hence mddev should not be used anymore after
export_rdev().
This problem can be triggered by following test for mdadm at very
low rate:
New file: mdadm/tests/23rdev-lifetime
devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2
clean_up_test() {
pill -9 $pid
echo clear > /sys/block/md0/md/array_state
}
trap 'clean_up_test' EXIT
add_by_sysfs() {
while true; do
echo $devt > /sys/block/md0/md/new_dev
done
}
remove_by_sysfs(){
while true; do
echo remove > /sys/block/md0/md/dev-${devname}/state
done
}
echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"
add_by_sysfs &
pid="$pid $!"
remove_by_sysfs &
pid="$pid $!"
sleep $runtime
exit 0
Test cmd:
./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime
Test result:
general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP
CPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562
RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]
Call Trace:
<TASK>
mddev_unlock+0x1b6/0x310 [md_mod]
rdev_attr_store+0xec/0x190 [md_mod]
sysfs_kf_write+0x52/0x70
kernfs_fop_write_iter+0x19a/0x2a0
vfs_write+0x3b5/0x770
ksys_write+0x74/0x150
__x64_sys_write+0x22/0x30
do_syscall_64+0x40/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fix this problem by don't dereference mddev after export_rdev(). |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Check instead of asserting on nested TSC scaling support
Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default. Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking
KVM's state_test selftest to do
vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);
after restoring state in a new VM+vCPU yields an endless supply of:
------------[ cut here ]------------
WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
Call Trace:
<TASK>
enter_svm_guest_mode+0x114/0x560 [kvm_amd]
nested_svm_vmrun+0x260/0x330 [kvm_amd]
vmrun_interception+0x29/0x30 [kvm_amd]
svm_invoke_exit_handler+0x35/0x100 [kvm_amd]
svm_handle_exit+0xe7/0x180 [kvm_amd]
kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
__se_sys_ioctl+0x7a/0xc0
__x64_sys_ioctl+0x21/0x30
do_syscall_64+0x41/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x45ca1b
Note, the nested #VMEXIT path has the same flaw, but needs a different
fix and will be handled separately. |
| IBM DB2 Merge Backup for Linux, UNIX and Windows 12.1.0.0 could allow an attacker to access sensitive information in memory due to the buffer not properly clearing resources. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Zero padding when dumping algos and encap
When copying data to user-space we should ensure that only valid
data is copied over. Padding in structures may be filled with
random (possibly sensitve) data and should never be given directly
to user-space.
This patch fixes the copying of xfrm algorithms and the encap
template in xfrm_user so that padding is zeroed. |
| pgAdmin versions 9.11 are affected by a Restore restriction bypass via key disclosure vulnerability that occurs when running in server mode and performing restores from PLAIN-format dump files. An attacker with access to the pgAdmin web interface can observe an active restore operation, extract the `\restrict` key in real time, and race the restore process by overwriting the restore script with a payload that re-enables meta-commands using `\unrestrict <key>`. This results in reliable command execution on the pgAdmin host during the restore operation. |
| A flaw was found in Moodle. An authorization logic flaw, specifically due to incomplete role checks during the badge awarding process, allowed badges to be granted without proper verification. This could enable unauthorized users to obtain badges they are not entitled to, potentially leading to privilege escalation or unauthorized access to certain features. |
| Remote prevention of access to cellular service with no user interaction (for example, crashing the cellular radio service with a malformed packet) |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: restore destructor on submit failure
handshake_req_submit() replaces sk->sk_destruct but never restores it when
submission fails before the request is hashed. handshake_sk_destruct() then
returns early and the original destructor never runs, leaking the socket.
Restore sk_destruct on the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
gve: defer interrupt enabling until NAPI registration
Currently, interrupts are automatically enabled immediately upon
request. This allows interrupt to fire before the associated NAPI
context is fully initialized and cause failures like below:
[ 0.946369] Call Trace:
[ 0.946369] <IRQ>
[ 0.946369] __napi_poll+0x2a/0x1e0
[ 0.946369] net_rx_action+0x2f9/0x3f0
[ 0.946369] handle_softirqs+0xd6/0x2c0
[ 0.946369] ? handle_edge_irq+0xc1/0x1b0
[ 0.946369] __irq_exit_rcu+0xc3/0xe0
[ 0.946369] common_interrupt+0x81/0xa0
[ 0.946369] </IRQ>
[ 0.946369] <TASK>
[ 0.946369] asm_common_interrupt+0x22/0x40
[ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10
Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto
enablement and explicitly enable the interrupt in NAPI initialization
path (and disable it during NAPI teardown).
This ensures that interrupt lifecycle is strictly coupled with
readiness of NAPI context. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: always drop device refcount in ib_del_sub_device_and_put()
Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add
support to add/delete a sub IB device through netlink") grabs a reference
using ib_device_get_by_index() before calling ib_del_sub_device_and_put(),
we need to drop that reference before returning -EOPNOTSUPP error. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: avoid chain re-validation if possible
Hamza Mahfooz reports cpu soft lock-ups in
nft_chain_validate():
watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]
[..]
RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_immediate_validate+0x36/0x50 [nf_tables]
nft_chain_validate+0xc9/0x110 [nf_tables]
nft_table_validate+0x6b/0xb0 [nf_tables]
nf_tables_validate+0x8b/0xa0 [nf_tables]
nf_tables_commit+0x1df/0x1eb0 [nf_tables]
[..]
Currently nf_tables will traverse the entire table (chain graph), starting
from the entry points (base chains), exploring all possible paths
(chain jumps). But there are cases where we could avoid revalidation.
Consider:
1 input -> j2 -> j3
2 input -> j2 -> j3
3 input -> j1 -> j2 -> j3
Then the second rule does not need to revalidate j2, and, by extension j3,
because this was already checked during validation of the first rule.
We need to validate it only for rule 3.
This is needed because chain loop detection also ensures we do not exceed
the jump stack: Just because we know that j2 is cycle free, its last jump
might now exceed the allowed stack size. We also need to update all
reachable chains with the new largest observed call depth.
Care has to be taken to revalidate even if the chain depth won't be an
issue: chain validation also ensures that expressions are not called from
invalid base chains. For example, the masquerade expression can only be
called from NAT postrouting base chains.
Therefore we also need to keep record of the base chain context (type,
hooknum) and revalidate if the chain becomes reachable from a different
hook location. |
| Improper access control in SecSettingsIntelligence prior to SMR Mar-2025 Release 1 allows local attackers to launch privileged activities. User interaction is required for triggering this vulnerability. |
| Improper neutralization in Microsoft Management Console allows an unauthorized attacker to bypass a security feature locally. |
| .NET Remote Code Execution Vulnerability |
| Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability |
| Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability |
