{"vulnerability": "cve-2025-21913", "sightings": [{"uuid": "b48cfb66-8e9d-4b8f-9032-7d22fed004bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2025-21913", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-04", "content": "", "creation_timestamp": "2026-07-28T16:17:49.321931Z"}, {"uuid": "eec97a24-3f3d-42de-9ca5-8d24baa82560", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-21913", "type": "seen", "source": "https://infosec.exchange/users/andersonc0d3/statuses/117202687407493983", "content": "RE: https://infosec.exchange/@andersonc0d3/117197828727921773\nThe exception table mechanism in the page fault handler is popular, but maybe the mechanism in the general protection handler isn't so well-known.\nWhen the code is interacting with MSRs, if the MSR index/address is invalid for the architecture, it triggers a #GP and the kernel oopses. This can happen in some scenarios and most of the cases it shouldn't trigger an oops and crash the kernel. That's why there are two MSR access implementations: rdmsr() / rdmsrq() and rdmsr_safe() / rdmsrq_safe(). The rdmsr variants use split 32-bit values for high/low bits, while rdmsrq handles 64-bit quadwords directly.\nThere is a proposal to retire legacy 32-bit user-space MSR interfaces, but I haven't followed this closely.\nLinux Preparing To Retire Its 32-bit MSR Interfaceshttps://www.phoronix.com/news/Linux-Ending-32-bit-MSR-Work\nThe safe ones are supposed to not crash/oops the kernel when the #GP is issued. It implements the same exception table mechanism present in the page fault handler. That's why it contains *_safe() in the function name.\nThis is checked by the general protection fault handler via fixup_exception() at line below:\nhttps://github.com/torvalds/linux/blob/master/arch/x86/kernel/traps.c#L949\nThere was an oops caused by the use of rdmsrl() when running the Linux kernel as a Xen guest and the fix was to replace rdmsrl() with rdmsrl_safe().\nCVE-2025-21913: x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()https://lore.kernel.org/linux-cve-announce/2025040130-CVE-2025-21913-b942@gregkh/T\nx86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14cb5d83068ecf15d2da6f7d0e9ea9edbcbc0457\nThe interface was rdmsrl before being renamed to rdmsrq.\nIn the case of virtualization, things get more complicated because the hypervisor might have different configurations. That issue in the Linux kernel seems to have been exposed due to a change in Xen regarding MSRs accesses.\nxen/pv: support selecting safe/unsafe msr accesses https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3fac3734c43a2e21fefeb72124d8bd31dff3956f", "creation_timestamp": "2026-09-02T17:44:45.393030Z"}]}