Kernel Pointer Leak impacting KASLR

[brmonroe]

I've got a question on kernel pointer leaks weakening KASLR. We have been getting a number of reports regarding kernel pointer leaks. Without being paired with another vulnerability these are not exploitable on their own. I've polled the PSIRT SIG and have had discussions with industry peers, but there not consensus on how these should be handled.

Should we be issuing a CVE for these kernel pointer leaks?

Thanks,
Bruce Monroe
AMD PSIRT

[zmanion]

Hi @brmonroe, first, I'll give the easy answer, my individual opinion, as of this moment, is that behavior wouldn't quite make the vulnerability determination bar, so no CVE ID assignment. My probably simplistic understanding is that KASLR is a defensive or hardening mechanism, not having KASLR (or other exploit mitigation techniques) in place does not qualify as a CVE-worthy vulnerability. Kernel addresses aren't secret and knowing them doesn't constitute an exploit, KASLR is (a perhaps limited) technique to make address discovery a little more costly.

Hopefully a more rules-based answer:

1. CNAs are expected and permitted to use judgment (4.4)

2. Disagreement is allowed, which would lead to the dispute process

3. "exploit mitigation bypass"seems similar to "detection bypass" (4.1.7), which "...SHOULD NOT be determined to be Vulnerabilities unless, for example, a Product explicitly claims to detect a specific pattern and fails to do so." I don't think KASLR promises to prevent all kernel memory exploits.

I don't see a rules edit here, although maybe 4.1.7 could be expanded or duplicated to cover exploit mitigation techniques

Suggestion:

Bypassing detection, exploit mitigation, or other hardening mechanisms SHOULD NOT be determined to be a Vulnerability. If a mechanism substantially fails to meet an explicit claim, that failure MAY be determined to be a Vulnerability.

[brmonroe]

[AMD Official Use Only - AMD Internal Distribution Only] @Art ***@***.***> we met and discussed with our fellow travelers at Intel yesterday. We settled on if it’s coding errors in something solely maintained by our companies that led to a kernel pointer leak we would provide a CVE. In the cases I’m referring to it’s coding error in graphics drivers produced by AMD. Also chatted with peers at Microsoft and they treat these as a high severity issue but an OSV has a different view than a hardware vendor. With the exception of above instance we do not plan to provide a CVE. Thoughts? Thanks, Bruce From: Art Manion ***@***.***> Sent: Tuesday, January 20, 2026 4:56 PM To: CVEProject/cve-documents ***@***.***> Cc: Monroe, Bruce ***@***.***>; Mention ***@***.***> Subject: Re: [CVEProject/cve-documents] Kernel Pointer Leak impacting KASLR (Issue #31) Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. [https://avatars.githubusercontent.com/u/18131334?s=20&v=4]zmanion left a comment (CVEProject/cve-documents#31)<#31 (comment)> Hi @brmonroe<https://github.com/brmonroe>, first, I'll give the easy answer, my individual opinion, as of this moment, is that behavior wouldn't quite make the vulnerability determination bar, so no CVE ID assignment. My probably simplistic understanding is that KASLR is a defensive or hardening mechanism, not having KASLR (or other exploit mitigation techniques) in place does not qualify as a CVE-worthy vulnerability. Kernel addresses aren't secret and knowing them doesn't constitute an exploit, KASLR is (a perhaps limited) technique to make address discovery a little more costly. Hopefully a more rules-based answer: 1. CNAs are expected and permitted to use judgment (4.4<https://www.cve.org/ResourcesSupport/AllResources/CNARules/#section_4-4_CNA_Judgment>) 2. Disagreement is allowed, which would lead to the dispute process 3. "exploit mitigation bypass"seems similar to "detection bypass" (4.1.7), which "...SHOULD NOT be determined to be Vulnerabilities unless, for example, a Product explicitly claims to detect a specific pattern and fails to do so." I don't think KASLR promises to prevent all kernel memory exploits. I don't see a rules edit here, although maybe 4.1.7 could be expanded or duplicated to cover exploit mitigation techniques Suggestion: Bypassing detection, exploit mitigation, or other hardening mechanisms SHOULD NOT be determined to be a Vulnerability. If a mechanism substantially fails to meet an explicit claim, that failure MAY be determined to be a Vulnerability. — Reply to this email directly, view it on GitHub<#31 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BRJIB34ORO6CO52JTQXZ62D4H2QATAVCNFSM6AAAAACSJNQSWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONZVGEZTGMRVGA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[zmanion]

Is some behavior of ASLR (or some other detection or exploit mitigation technique) vul or not?

1. coding error in the ASLR implementation: yes (actual bug that can be fixed, to get you back to state 2).
2. ASLR simply isn't perfect: no (expected detection bypass)

"...a Product explicitly claims to detect a specific pattern and fails to do so" is too narrow, rewrite to "implementation defect/bug in the detection mechanism."