| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated
Explicitly set/clear CR8 write interception when AVIC is (de)activated to
fix a bug where KVM leaves the interception enabled after AVIC is
activated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8
will remain intercepted in perpetuity.
On its own, the dangling CR8 intercept is "just" a performance issue, but
combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM:
Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging
intercept is fatal to Windows guests as the TPR seen by hardware gets
wildly out of sync with reality.
Note, VMX isn't affected by the bug as TPR_THRESHOLD is explicitly ignored
when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in
KVM's world. I.e. there's no need to trigger update_cr8_intercept(), this
is firmly an SVM implementation flaw/detail.
WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should
never enter the guest with AVIC enabled and CR8 writes intercepted.
[Squash fix to avic_deactivate_vmcb. - Paolo] |
| Improper initialization in the UEFI firmware for some Intel platforms within Ring 0: Bare Metal OS may allow an information disclosure. System software adversary with a privileged user combined with a high complexity attack may enable data exposure. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (high), integrity (none) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: initialise extack before use
Fix missing initialisation of extack in flow offload. |
| In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
- OVS_PACKET_ATTR_PACKET - Binary packet content.
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
with the metadata like conntrack state, input port, recirculation id,
etc. Then the packet itself gets parsed to populate the rest of the
keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it
first zeroes out fields in the key corresponding to Neighbor Discovery
information even if it is not an ND packet.
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares
the space between 'nd' and 'ct_orig' that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
ND packets should not normally have conntrack state, so it's fine to
share the space, but normal ICMPv6 Echo packets or maybe other types of
ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination
address being wiped from the original conntrack tuple leading to
incorrect packet matching and potentially executing wrong actions
in case this packet recirculates within the datapath or goes back
to userspace.
ND fields should not be accessed in non-ND packets, so not clearing
them should be fine. Executing memset() only for actual ND packets to
avoid the issue.
Initializing the whole thing before parsing is needed because ND packet
may not contain all the options.
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
affect packets entering OVS datapath from network interfaces, because
in this case CT metadata is populated from skb after the packet is
already parsed. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Set hugetlb mmap base address aligned with pmd size
With ltp test case "testcases/bin/hugefork02", there is a dmesg error
report message such as:
kernel BUG at mm/hugetlb.c:5550!
Oops - BUG[#1]:
CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241
Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940
a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000
a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000
t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000
t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001
t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280
s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10
s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08
ra: 9000000000485538 unmap_vmas+0x130/0x218
ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)
Call Trace:
[<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0
[<9000000000485534>] unmap_vmas+0x12c/0x218
[<9000000000494068>] exit_mmap+0xe0/0x308
[<900000000025fdc4>] mmput+0x74/0x180
[<900000000026a284>] do_exit+0x294/0x898
[<900000000026aa30>] do_group_exit+0x30/0x98
[<900000000027bed4>] get_signal+0x83c/0x868
[<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0
[<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138
[<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4
The problem is that base address allocated from hugetlbfs is not aligned
with pmd size. Here add a checking for hugetlbfs and align base address
with pmd size. After this patch the test case "testcases/bin/hugefork02"
passes to run.
This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach
generic_get_unmapped_area{_topdown} to handle hugetlb mappings"). |
| In the Linux kernel, the following vulnerability has been resolved:
media: v4l: async: Properly re-initialise notifier entry in unregister
The notifier_entry of a notifier is not re-initialised after unregistering
the notifier. This leads to dangling pointers being left there so use
list_del_init() to return the notifier_entry an empty list. |
| In the Linux kernel, the following vulnerability has been resolved:
efi: libstub: only free priv.runtime_map when allocated
priv.runtime_map is only allocated when efi_novamap is not set.
Otherwise, it is an uninitialized value. In the error path, it is freed
unconditionally. Avoid passing an uninitialized value to free_pool.
Free priv.runtime_map only when it was allocated.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Reset register ID for BPF_END value tracking
When a register undergoes a BPF_END (byte swap) operation, its scalar
value is mutated in-place. If this register previously shared a scalar ID
with another register (e.g., after an `r1 = r0` assignment), this tie must
be broken.
Currently, the verifier misses resetting `dst_reg->id` to 0 for BPF_END.
Consequently, if a conditional jump checks the swapped register, the
verifier incorrectly propagates the learned bounds to the linked register,
leading to false confidence in the linked register's value and potentially
allowing out-of-bounds memory accesses.
Fix this by explicitly resetting `dst_reg->id` to 0 in the BPF_END case
to break the scalar tie, similar to how BPF_NEG handles it via
`__mark_reg_known`. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: target: tcm_loop: Drain commands in target_reset handler
tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS
without draining any in-flight commands. The SCSI EH documentation
(scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver
has made lower layers "forget about timed out scmds" and is ready for new
commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,
mpi3mr) enforces this by draining or completing outstanding commands before
returning SUCCESS.
Because tcm_loop_target_reset() doesn't drain, the SCSI EH reuses in-flight
scsi_cmnd structures for recovery commands (e.g. TUR) while the target core
still has async completion work queued for the old se_cmd. The memset in
queuecommand zeroes se_lun and lun_ref_active, causing
transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN
reference prevents transport_clear_lun_ref() from completing, hanging
configfs LUN unlink forever in D-state:
INFO: task rm:264 blocked for more than 122 seconds.
rm D 0 264 258 0x00004000
Call Trace:
__schedule+0x3d0/0x8e0
schedule+0x36/0xf0
transport_clear_lun_ref+0x78/0x90 [target_core_mod]
core_tpg_remove_lun+0x28/0xb0 [target_core_mod]
target_fabric_port_unlink+0x50/0x60 [target_core_mod]
configfs_unlink+0x156/0x1f0 [configfs]
vfs_unlink+0x109/0x290
do_unlinkat+0x1d5/0x2d0
Fix this by making tcm_loop_target_reset() actually drain commands:
1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that
the target core knows about (those not yet CMD_T_COMPLETE).
2. Use blk_mq_tagset_busy_iter() to iterate all started requests and
flush_work() on each se_cmd — this drains any deferred completion work
for commands that already had CMD_T_COMPLETE set before the TMR (which
the TMR skips via __target_check_io_state()). This is the same pattern
used by mpi3mr, scsi_debug, and libsas to drain outstanding commands
during reset. |
| In the Linux kernel, the following vulnerability has been resolved:
mfd: macsmc: Initialize mutex
Initialize struct apple_smc's mutex in apple_smc_probe(). Using the
mutex uninitialized surprisingly resulted only in occasional NULL
pointer dereferences in apple_smc_read() calls from the probe()
functions of sub devices. |
| The Hash-based Message Authentication Code (HMAC) provider in Java on Apple Mac OS X 10.4.11, 10.5.4, and 10.5.5 uses an uninitialized variable, which allows remote attackers to execute arbitrary code via a crafted applet, related to an "error checking issue." |
| KDC in MIT Kerberos 5 (krb5kdc) does not set a global variable for some krb4 message types, which allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted messages that trigger a NULL pointer dereference or double-free. |
| The kernel in Apple Mac OS X 10.4 through 10.4.10 does not reset the current Mach Thread Port or Thread Exception Port when executing a setuid program, which allows local users to execute arbitrary code by creating the port before launching the setuid program, then writing to the address space of the setuid process. |
| Mozilla Firefox before 21.0, Firefox ESR 17.x before 17.0.6, Thunderbird before 17.0.6, and Thunderbird ESR 17.x before 17.0.6 do not properly initialize data structures for the nsDOMSVGZoomEvent::mPreviousScale and nsDOMSVGZoomEvent::mNewScale functions, which allows remote attackers to obtain sensitive information from process memory via a crafted web site. |
| Uninitialized memory in the JavaScript Engine component. This vulnerability was fixed in Firefox 142, Firefox ESR 128.14, Firefox ESR 140.2, Thunderbird 142, Thunderbird 128.14, and Thunderbird 140.2. |
| iccDEV provides a set of libraries and tools for working with ICC color management profiles. Prior to version 2.3.1.6, there is a defect in LUT dump/iteration logic affecting CIccCLUT::Iterate() and output produced by CIccMBB::Describe() (via CLUT dumping). This issue has been patched in version 2.3.1.6. |
| In the context switch logic Xen attempts to skip an IBPB in the case of
a vCPU returning to a CPU on which it was the previous vCPU to run.
While safe for Xen's isolation between vCPUs, this prevents the guest
kernel correctly isolating between tasks. Consider:
1) vCPU runs on CPU A, running task 1.
2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB.
3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB.
4) vCPU moves back to CPU A. Xen skips IBPB again.
Now, task 2 is running on CPU A with task 1's training still in the BTB. |
| In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix device mismatch in devm_kzalloc/devm_kfree
Initial rss_hdr allocation uses virtio_device->device,
but virtnet_set_queues() frees using net_device->device.
This device mismatch causing below devres warning
[ 3788.514041] ------------[ cut here ]------------
[ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463
[ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]
[ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT
[ 3788.514067] Tainted: [W]=WARN
[ 3788.514069] Hardware name: Marvell CN106XX board (DT)
[ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[ 3788.514074] pc : devm_kfree+0x84/0x98
[ 3788.514076] lr : devm_kfree+0x54/0x98
[ 3788.514079] sp : ffff800084e2f220
[ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f
[ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080
[ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018
[ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000
[ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff
[ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff
[ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c
[ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f
[ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080
[ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000
[ 3788.514123] Call trace:
[ 3788.514125] devm_kfree+0x84/0x98 (P)
[ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]
[ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]
[ 3788.514139] virtio_dev_probe+0x1e0/0x338
[ 3788.514144] really_probe+0xc8/0x3a0
[ 3788.514149] __driver_probe_device+0x84/0x170
[ 3788.514152] driver_probe_device+0x44/0x120
[ 3788.514155] __device_attach_driver+0xc4/0x168
[ 3788.514158] bus_for_each_drv+0x8c/0xf0
[ 3788.514161] __device_attach+0xa4/0x1c0
[ 3788.514164] device_initial_probe+0x1c/0x30
[ 3788.514168] bus_probe_device+0xb4/0xc0
[ 3788.514170] device_add+0x614/0x828
[ 3788.514173] register_virtio_device+0x214/0x258
[ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]
[ 3788.514179] vdpa_dev_probe+0xa8/0xd8
[ 3788.514183] really_probe+0xc8/0x3a0
[ 3788.514186] __driver_probe_device+0x84/0x170
[ 3788.514189] driver_probe_device+0x44/0x120
[ 3788.514192] __device_attach_driver+0xc4/0x168
[ 3788.514195] bus_for_each_drv+0x8c/0xf0
[ 3788.514197] __device_attach+0xa4/0x1c0
[ 3788.514200] device_initial_probe+0x1c/0x30
[ 3788.514203] bus_probe_device+0xb4/0xc0
[ 3788.514206] device_add+0x614/0x828
[ 3788.514209] _vdpa_register_device+0x58/0x88
[ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]
[ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0
[ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158
[ 3788.514222] genl_rcv_msg+0x218/0x298
[ 3788.514225] netlink_rcv_skb+0x64/0x138
[ 3788.514229] genl_rcv+0x40/0x60
[ 3788.514233] netlink_unicast+0x32c/0x3b0
[ 3788.514237] netlink_sendmsg+0x170/0x3b8
[ 3788.514241] __sys_sendto+0x12c/0x1c0
[ 3788.514246] __arm64_sys_sendto+0x30/0x48
[ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8
[ 3788.514255] do_el0_svc+0x48/0xd0
[ 3788.514259] el0_svc+0x48/0x210
[ 3788.514264] el0t_64_sync_handler+0xa0/0xe8
[ 3788.514268] el0t_64_sync+0x198/0x1a0
[ 3788.514271] ---[ end trace 0000000000000000 ]---
Fix by using virtio_device->device consistently for
allocation and deallocation |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel
The connector type for the DataImage SCF0700C48GGU18 panel is missing and
devm_drm_panel_bridge_add() requires connector type to be set. This leads
to a warning and a backtrace in the kernel log and panel does not work:
"
WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8
"
The warning is triggered by a check for valid connector type in
devm_drm_panel_bridge_add(). If there is no valid connector type
set for a panel, the warning is printed and panel is not added.
Fill in the missing connector type to fix the warning and make
the panel operational once again. |
| An Incorrect Initialization of Resource vulnerability in the Internal Device Manager (IDM) of Juniper Networks Junos OS on EX4000 models allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).
On EX4000 models with 48 ports (EX4000-48T, EX4000-48P, EX4000-48MP) a high volume of traffic destined to the device will cause an FXPC crash and restart, which leads to a complete service outage until the device has automatically restarted.
The following reboot reason can be seen in the output of 'show chassis routing-engine' and as a log message:
reason=0x4000002 reason_string=0x4000002:watchdog + panic with core dump
This issue affects Junos OS on EX4000-48T, EX4000-48P and EX4000-48MP:
* 24.4 versions before 24.4R2,
* 25.2 versions before 25.2R1-S2, 25.2R2.
This issue does not affect versions before 24.4R1 as the first Junos OS version for the EX4000 models was 24.4R1. |
