Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2026-81016

Опубликовано: 11 сент. 2026
Источник: redhat
CVSS3: 5.5
EPSS Низкий

Описание

In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().

A flaw was found in the Linux kernel. Specifically, within the AMD Platform Management Controller (PMC) component, the amd_stb_s2d_init() function does not properly validate memory addresses returned by System Management Unit (SMU) commands. This can result in the kernel attempting to map a critical memory region at address zero, leading to system warnings and potential instability. This issue could be exploited by a local attacker to cause a denial of service.

Отчет

A flaw was found in the Linux kernel AMD Platform Management Controller (PMC) driver. In amd_stb_s2d_init(), the return values of several Spill-to-DRAM (S2D) SMU commands are discarded, so when the SMU refuses a command the failure is only noticed indirectly and masked as a generic -EIO, and the S2D_PHYS_ADDR_LOW/HIGH values are left uninitialized. The resulting physical address is passed directly to devm_ioremap(), which can map physical address 0 and trigger an ioremap-on-RAM warning and potential kernel panic. A local attacker could leverage this flaw to cause a denial of service. Red Hat rated this flaw as Moderate severity (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H); the upstream CVEORG score of 7.7 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H) differs because it assumes no privileges are required and a high confidentiality impact, whereas the technical evidence for this flaw shows it requires local access and affects only availability. The kernel in Red Hat Enterprise Linux 9 and Red Hat Enterprise Linux 10, and the RHEL 9-based RHCOS 9 components shipped in OpenShift Container Platform 4.13 and later, are affected. The fix is currently deferred for these affected streams because Red Hat does not file trackers for MODERATE severity flaws whose CVSS score is below 7.0; the residual risk is that on an affected AMD platform whose SMU refuses S2D commands, the unvalidated address passed to devm_ioremap() can lead to a kernel warning or panic, resulting in local denial of service. Red Hat Enterprise Linux 6, 7, and 8 kernels (including kernel-rt) and the RHEL 8-based RHCOS 8 component shipped in OpenShift Container Platform 4.12 are not affected because the vulnerable code is not present in those kernels.

Меры по смягчению последствий

Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Enterprise Linux 10kernelFix deferred
Red Hat Enterprise Linux 6kernelNot affected
Red Hat Enterprise Linux 7kernelNot affected
Red Hat Enterprise Linux 7kernel-rtNot affected
Red Hat Enterprise Linux 8kernelNot affected
Red Hat Enterprise Linux 8kernel-rtNot affected
Red Hat Enterprise Linux 9kernelFix deferred
Red Hat Enterprise Linux 9kernel-rtFix deferred
Red Hat OpenShift Container Platform 4openshift/ose-rhel-coreos-8Not affected
Red Hat OpenShift Container Platform 4openshift/ose-rhel-coreos-9Fix deferred

Показывать по

Дополнительная информация

Статус:

Moderate
Дефект:
CWE-908
https://bugzilla.redhat.com/show_bug.cgi?id=2532049kernel: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address

EPSS

Процентиль: 8%
0.00186
Низкий

5.5 Medium

CVSS3

Связанные уязвимости

CVSS3: 7.7
ubuntu
около 2 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().

CVSS3: 7.7
nvd
около 2 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().

CVSS3: 7.7
debian
около 2 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: p ...

CVSS3: 7.7
github
около 2 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Propagate SMU errors and validate S2D address amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error. More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap(). When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning: amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:... Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().

oracle-oval
7 дней назад

ELSA-2026-500572: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS

Процентиль: 8%
0.00186
Низкий

5.5 Medium

CVSS3