| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A use after free in the SEV firmware could allow a malicous hypervisor to activate a migrated guest with the SINGLE_SOCKET policy on a different socket than the migration agent potentially resulting in loss of integrity. |
| Improper handling of error condition during host-induced faults can allow a local high-privileged attack to selectively drop guest DMA writes, potentially resulting in a loss of SEV-SNP guest memory integrity |
| Insufficient or Incomplete Data Removal in Hardware Component in SEV firmware doesn't fully flush IOMMU. This can potentially lead to a loss of confidentiality and integrity in guest memory. |
| Improper input validation in the SMM communications buffer could allow a privileged attacker to perform an out of bounds read or write to SMRAM potentially resulting in loss of confidentiality or integrity. |
| Insufficient input parameter sanitization in AMD Secure Processor (ASP) Boot Loader (legacy recovery mode only) could allow an attacker to write out-of-bounds to corrupt Secure DRAM potentially resulting in denial of service. |
| Insufficient parameter sanitization in AMD Secure Processor (ASP) Boot Loader could allow an attacker with access to SPIROM upgrade to overwrite the memory, potentially resulting in arbitrary code execution. |
| A Time-of-check time-of-use (TOCTOU) race condition in the SMM communications buffer could allow a privileged attacker to bypass input validation and perform an out of bounds read or write, potentially resulting in loss of confidentiality, integrity, or availability. |
| The integer overflow vulnerability within AMD Graphics driver could allow an attacker to bypass size checks potentially resulting in a denial of service |
| Integer Overflow within atihdwt6.sys can allow a local attacker to cause out of bound read/write potentially leading to loss of confidentiality, integrity and availability |
| A Time-of-check time-of-use (TOCTOU) race condition in the AMD Secure Processor (ASP) could allow an attacker to modify External Global Memory Interconnect Trusted Agent (XGMI TA) commands as they are processed potentially resulting in loss of confidentiality, integrity, or availability. |
| A Time-of-check time-of-use (TOCTOU) race condition in the AMD Secure Processor (ASP) could allow an attacker to corrupt memory resulting in loss of integrity, confidentiality, or availability. |
| No description is available for this CVE. |
| Emmett is a framework designed to simplify your development process. Prior to 1.3.11, the cookies property in mmett_core.http.wrappers.Request does not handle CookieError exceptions when parsing malformed Cookie headers. This allows unauthenticated attackers to trigger HTTP 500 errors and cause denial of service. This vulnerability is fixed in 1.3.11. |
| An high privileged remote attacker can inject arbitrary content into the custom CSS field on the affected devices due to improper neutralization of input during web page generation ('Cross-site Scripting'). |
| In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Fix race in push_rt_task
Overview
========
When a CPU chooses to call push_rt_task and picks a task to push to
another CPU's runqueue then it will call find_lock_lowest_rq method
which would take a double lock on both CPUs' runqueues. If one of the
locks aren't readily available, it may lead to dropping the current
runqueue lock and reacquiring both the locks at once. During this window
it is possible that the task is already migrated and is running on some
other CPU. These cases are already handled. However, if the task is
migrated and has already been executed and another CPU is now trying to
wake it up (ttwu) such that it is queued again on the runqeue
(on_rq is 1) and also if the task was run by the same CPU, then the
current checks will pass even though the task was migrated out and is no
longer in the pushable tasks list.
Crashes
=======
This bug resulted in quite a few flavors of crashes triggering kernel
panics with various crash signatures such as assert failures, page
faults, null pointer dereferences, and queue corruption errors all
coming from scheduler itself.
Some of the crashes:
-> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO)
Call Trace:
? __die_body+0x1a/0x60
? die+0x2a/0x50
? do_trap+0x85/0x100
? pick_next_task_rt+0x6e/0x1d0
? do_error_trap+0x64/0xa0
? pick_next_task_rt+0x6e/0x1d0
? exc_invalid_op+0x4c/0x60
? pick_next_task_rt+0x6e/0x1d0
? asm_exc_invalid_op+0x12/0x20
? pick_next_task_rt+0x6e/0x1d0
__schedule+0x5cb/0x790
? update_ts_time_stats+0x55/0x70
schedule_idle+0x1e/0x40
do_idle+0x15e/0x200
cpu_startup_entry+0x19/0x20
start_secondary+0x117/0x160
secondary_startup_64_no_verify+0xb0/0xbb
-> BUG: kernel NULL pointer dereference, address: 00000000000000c0
Call Trace:
? __die_body+0x1a/0x60
? no_context+0x183/0x350
? __warn+0x8a/0xe0
? exc_page_fault+0x3d6/0x520
? asm_exc_page_fault+0x1e/0x30
? pick_next_task_rt+0xb5/0x1d0
? pick_next_task_rt+0x8c/0x1d0
__schedule+0x583/0x7e0
? update_ts_time_stats+0x55/0x70
schedule_idle+0x1e/0x40
do_idle+0x15e/0x200
cpu_startup_entry+0x19/0x20
start_secondary+0x117/0x160
secondary_startup_64_no_verify+0xb0/0xbb
-> BUG: unable to handle page fault for address: ffff9464daea5900
kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p))
-> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running)
Call Trace:
? __die_body+0x1a/0x60
? die+0x2a/0x50
? do_trap+0x85/0x100
? dequeue_top_rt_rq+0xa2/0xb0
? do_error_trap+0x64/0xa0
? dequeue_top_rt_rq+0xa2/0xb0
? exc_invalid_op+0x4c/0x60
? dequeue_top_rt_rq+0xa2/0xb0
? asm_exc_invalid_op+0x12/0x20
? dequeue_top_rt_rq+0xa2/0xb0
dequeue_rt_entity+0x1f/0x70
dequeue_task_rt+0x2d/0x70
__schedule+0x1a8/0x7e0
? blk_finish_plug+0x25/0x40
schedule+0x3c/0xb0
futex_wait_queue_me+0xb6/0x120
futex_wait+0xd9/0x240
do_futex+0x344/0xa90
? get_mm_exe_file+0x30/0x60
? audit_exe_compare+0x58/0x70
? audit_filter_rules.constprop.26+0x65e/0x1220
__x64_sys_futex+0x148/0x1f0
do_syscall_64+0x30/0x80
entry_SYSCALL_64_after_hwframe+0x62/0xc7
-> BUG: unable to handle page fault for address: ffff8cf3608bc2c0
Call Trace:
? __die_body+0x1a/0x60
? no_context+0x183/0x350
? spurious_kernel_fault+0x171/0x1c0
? exc_page_fault+0x3b6/0x520
? plist_check_list+0x15/0x40
? plist_check_list+0x2e/0x40
? asm_exc_page_fault+0x1e/0x30
? _cond_resched+0x15/0x30
? futex_wait_queue_me+0xc8/0x120
? futex_wait+0xd9/0x240
? try_to_wake_up+0x1b8/0x490
? futex_wake+0x78/0x160
? do_futex+0xcd/0xa90
? plist_check_list+0x15/0x40
? plist_check_list+0x2e/0x40
? plist_del+0x6a/0xd0
? plist_check_list+0x15/0x40
? plist_check_list+0x2e/0x40
? dequeue_pushable_task+0x20/0x70
? __schedule+0x382/0x7e0
? asm_sysvec_reschedule_i
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()
when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX") |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: uprobes: Add missing fence.i after building the XOL buffer
The XOL (execute out-of-line) buffer is used to single-step the
replaced instruction(s) for uprobes. The RISC-V port was missing a
proper fence.i (i$ flushing) after constructing the XOL buffer, which
can result in incorrect execution of stale/broken instructions.
This was found running the BPF selftests "test_progs:
uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the
uprobes tests randomly blew up. |
| In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix NULL pointer dereference in gfs2_log_flush
In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush
lock to provide exclusion against gfs2_log_flush().
In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before
dereferencing it. Otherwise, we could run into a NULL pointer
dereference when outstanding glock work races with an unmount
(glock_work_func -> run_queue -> do_xmote -> inode_go_sync ->
gfs2_log_flush). |
| Insertion of Sensitive Information into Externally-Accessible File or Directory vulnerability in Logo Software Industry and Trade Inc. Logo j-Platform allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Logo j-Platform: from 3.29.6.4 before 3.34.8.9. |
| A vulnerability in the TP-Link Archer c20 router with firmware version V6.6_230412 and earlier permits unauthorized individuals to bypass the authentication of some interfaces under the /cgi directory. When adding Referer: http://tplinkwifi.net to the the request, it will be recognized as passing the authentication. NOTE: this is disputed by the Supplier because the response to the API call is only "non-sensitive UI initialization variables." |
