peter/spectre-meltdown-checker
1
0
Fork 0
mirror of https://github.com/speed47/spectre-meltdown-checker.git synced 2026-04-02 05:07:07 +02:00
Code Issues Projects Releases Wiki Activity

enh: CVE-2024-36357 CVE-2024-36350 (TSA): inventory of sysfs strings + consider vuln if TSA mitigation forced to user/kernel on hypervisors

Browse Source
This commit is contained in:
Stéphane Lesimple
2026-04-01 21:00:48 +02:00
parent d05601ed3f
commit 8c3fb7b2cc
2 changed files with 131 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
src/vulns/CVE-2024-36350.sh
View File

@@ -9,7 +9,7 @@ check_CVE_2024_36350() {
# CVE-2024-36350 TSA-SQ (transient scheduler attack - store queue) - Linux mitigation check
check_CVE_2024_36350_linux() {
local status sys_interface_available msg kernel_tsa kernel_tsa_err smt_enabled ret
local status sys_interface_available msg kernel_tsa kernel_tsa_err smt_enabled
status=UNK
sys_interface_available=0
msg=''
@@ -17,10 +17,57 @@ check_CVE_2024_36350_linux() {
if sys_interface_check "$VULN_SYSFS_BASE/tsa"; then
# this kernel has the /sys interface, trust it over everything
sys_interface_available=1
#
# Complete sysfs message inventory for tsa
#
# all versions:
# "Not affected" (cpu_show_common, pre-existing)
#
# --- mainline ---
# d8010d4ba43e (v6.16-rc6, initial TSA sysfs):
# "Vulnerable" (TSA_MITIGATION_NONE)
# "Vulnerable: No microcode" (TSA_MITIGATION_UCODE_NEEDED)
# "Mitigation: Clear CPU buffers: user/kernel boundary" (TSA_MITIGATION_USER_KERNEL)
# "Mitigation: Clear CPU buffers: VM" (TSA_MITIGATION_VM)
# "Mitigation: Clear CPU buffers" (TSA_MITIGATION_FULL)
# 6b21d2f0dc73 (v6.17-rc1, attack vector controls):
# no string changes; only mitigation selection logic changed
# (AUTO can now resolve to USER_KERNEL or VM based on attack vector config)
#
# --- stable backports ---
# 6.16.y: d8010d4ba43e (same as mainline), same strings.
# 6.17.y: has 6b21d2f0dc73 (attack vector controls), same strings.
# 5.10.y (78192f511f40), 5.15.y (f2b75f1368af), 6.1.y (d12145e8454f),
# 6.6.y (90293047df18), 6.12.y (7a0395f6607a), 6.15.y (ab0f6573b211):
# different UCODE_NEEDED string:
# "Vulnerable: Clear CPU buffers attempted, no microcode" (TSA_MITIGATION_UCODE_NEEDED)
# all other strings identical to mainline.
# default is FULL (no AUTO enum); USER_KERNEL/VM only via cmdline tsa=user/tsa=vm.
# VM-forced mitigation: when UCODE_NEEDED and running in a VM, forces FULL
# (stable-only logic, not in mainline).
#
# --- RHEL/CentOS ---
# rocky9 (5.14-based), rocky10 (6.12-based): same strings as mainline.
# "Vulnerable: No microcode" for UCODE_NEEDED (matches mainline, NOT the stable variant).
# rocky8 (4.18-based), centos7 (3.10-based): no TSA support.
#
# all messages start with either "Not affected", "Mitigation", or "Vulnerable"
status=$ret_sys_interface_check_status
fi
if [ "$opt_sysfs_only" != 1 ]; then
check_has_vmm
# Override: when running as a hypervisor, "user/kernel boundary" mode
# (tsa=user) leaves the VM exit boundary uncovered — guests can exploit
# TSA to leak host data. The kernel correctly reports its own mode, but
# the script must flag this as insufficient for a VMM host.
if [ "$sys_interface_available" = 1 ] && [ "$g_has_vmm" != 0 ]; then
if echo "$ret_sys_interface_check_fullmsg" | grep -q 'user/kernel boundary'; then
status=VULN
msg="Vulnerable: TSA mitigation limited to user/kernel boundary (tsa=user), VM exit boundary is not covered"
fi
fi
pr_info_nol "* Kernel supports TSA mitigation: "
kernel_tsa=''
kernel_tsa_err=''
@@ -112,5 +159,19 @@ check_CVE_2024_36350_linux() {
fi
else
pvulnstatus "$cve" "$status" "$msg"
if echo "$msg" | grep -q 'VM exit boundary'; then
explain "This system runs a hypervisor but TSA mitigation only clears CPU buffers at\n " \
"user/kernel transitions (tsa=user). Guests can exploit TSA to leak host data\n " \
"across VM exit. Use \`tsa=on\` (or remove \`tsa=user\`) to cover both boundaries."
fi
fi
}
# CVE-2024-36350 TSA-SQ (transient scheduler attack - store queue) - BSD mitigation check
check_CVE_2024_36350_bsd() {
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
else
pvulnstatus "$cve" UNK "your CPU is affected, but mitigation detection has not yet been implemented for BSD in this script"
fi
}

70
src/vulns/CVE-2024-36357.sh
View File

@@ -9,7 +9,7 @@ check_CVE_2024_36357() {
# CVE-2024-36357 TSA-L1 (transient scheduler attack - L1 cache) - Linux mitigation check
check_CVE_2024_36357_linux() {
local status sys_interface_available msg kernel_tsa kernel_tsa_err ret
local status sys_interface_available msg kernel_tsa kernel_tsa_err
status=UNK
sys_interface_available=0
msg=''
@@ -17,10 +17,57 @@ check_CVE_2024_36357_linux() {
if sys_interface_check "$VULN_SYSFS_BASE/tsa"; then
# this kernel has the /sys interface, trust it over everything
sys_interface_available=1
#
# Complete sysfs message inventory for tsa
#
# all versions:
# "Not affected" (cpu_show_common, pre-existing)
#
# --- mainline ---
# d8010d4ba43e (v6.16-rc6, initial TSA sysfs):
# "Vulnerable" (TSA_MITIGATION_NONE)
# "Vulnerable: No microcode" (TSA_MITIGATION_UCODE_NEEDED)
# "Mitigation: Clear CPU buffers: user/kernel boundary" (TSA_MITIGATION_USER_KERNEL)
# "Mitigation: Clear CPU buffers: VM" (TSA_MITIGATION_VM)
# "Mitigation: Clear CPU buffers" (TSA_MITIGATION_FULL)
# 6b21d2f0dc73 (v6.17-rc1, attack vector controls):
# no string changes; only mitigation selection logic changed
# (AUTO can now resolve to USER_KERNEL or VM based on attack vector config)
#
# --- stable backports ---
# 6.16.y: d8010d4ba43e (same as mainline), same strings.
# 6.17.y: has 6b21d2f0dc73 (attack vector controls), same strings.
# 5.10.y (78192f511f40), 5.15.y (f2b75f1368af), 6.1.y (d12145e8454f),
# 6.6.y (90293047df18), 6.12.y (7a0395f6607a), 6.15.y (ab0f6573b211):
# different UCODE_NEEDED string:
# "Vulnerable: Clear CPU buffers attempted, no microcode" (TSA_MITIGATION_UCODE_NEEDED)
# all other strings identical to mainline.
# default is FULL (no AUTO enum); USER_KERNEL/VM only via cmdline tsa=user/tsa=vm.
# VM-forced mitigation: when UCODE_NEEDED and running in a VM, forces FULL
# (stable-only logic, not in mainline).
#
# --- RHEL/CentOS ---
# rocky9 (5.14-based), rocky10 (6.12-based): same strings as mainline.
# "Vulnerable: No microcode" for UCODE_NEEDED (matches mainline, NOT the stable variant).
# rocky8 (4.18-based), centos7 (3.10-based): no TSA support.
#
# all messages start with either "Not affected", "Mitigation", or "Vulnerable"
status=$ret_sys_interface_check_status
fi
if [ "$opt_sysfs_only" != 1 ]; then
check_has_vmm
# Override: when running as a hypervisor, "user/kernel boundary" mode
# (tsa=user) leaves the VM exit boundary uncovered — guests can exploit
# TSA to leak host data. The kernel correctly reports its own mode, but
# the script must flag this as insufficient for a VMM host.
if [ "$sys_interface_available" = 1 ] && [ "$g_has_vmm" != 0 ]; then
if echo "$ret_sys_interface_check_fullmsg" | grep -q 'user/kernel boundary'; then
status=VULN
msg="Vulnerable: TSA mitigation limited to user/kernel boundary (tsa=user), VM exit boundary is not covered"
fi
fi
pr_info_nol "* Kernel supports TSA mitigation: "
kernel_tsa=''
kernel_tsa_err=''
@@ -78,6 +125,13 @@ check_CVE_2024_36357_linux() {
elif [ -z "$msg" ]; then
# if msg is empty, sysfs check didn't fill it, rely on our own test
if [ "$opt_sysfs_only" != 1 ]; then
# No --paranoid SMT check here, unlike TSA-SQ (CVE-2024-36350).
# The kernel's cpu_bugs_smt_update() enables cpu_buf_idle_clear
# (VERW before idle) specifically for TSA-SQ cross-thread leakage,
# with the comment "TSA-SQ can potentially lead to info leakage
# between SMT threads" — TSA-L1 is not mentioned. Until the kernel
# flags TSA-L1 as having cross-thread SMT exposure, we follow its
# assessment and do not require SMT disabled in paranoid mode.
if [ "$cap_verw_clear" = 1 ] && [ -n "$kernel_tsa" ]; then
pvulnstatus "$cve" OK "Both kernel and microcode mitigate the vulnerability"
elif [ "$cap_verw_clear" = 1 ]; then
@@ -98,5 +152,19 @@ check_CVE_2024_36357_linux() {
fi
else
pvulnstatus "$cve" "$status" "$msg"
if echo "$msg" | grep -q 'VM exit boundary'; then
explain "This system runs a hypervisor but TSA mitigation only clears CPU buffers at\n " \
"user/kernel transitions (tsa=user). Guests can exploit TSA to leak host data\n " \
"across VM exit. Use \`tsa=on\` (or remove \`tsa=user\`) to cover both boundaries."
fi
fi
}
# CVE-2024-36357 TSA-L1 (transient scheduler attack - L1 cache) - BSD mitigation check
check_CVE_2024_36357_bsd() {
if ! is_cpu_affected "$cve"; then
pvulnstatus "$cve" OK "your CPU vendor reported your CPU model as not affected"
else
pvulnstatus "$cve" UNK "your CPU is affected, but mitigation detection has not yet been implemented for BSD in this script"
fi
}