A vulnerability in the context of the CVE Program is defined by the Counting Rules as listed in Appendix C. In general, a vulnerability is defined as a weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, OR availability. Mitigation of the vulnerabilities in this context typically involves coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety).”

A vulnerability is a flaw or design oversight in software that could be used by an attacker to
gain unintended access to a system or network. CVE considers a flaw a vulnerability if it allows
an attacker to use it to violate a reasonable security policy for that system (this excludes entirely
“open” security policies in which all users are trusted, or where there is no consideration of risk
to the system).

A vulnerability in the context of the CVE program is indicated by code that can be exploited, resulting in a negative impact to confidentiality, integrity, OR availability, and that requires a coding change, specification change, or specification deprecation to mitigate or address.

Dropping an iPhone would not be covered by the multiple versions of the definition of a vulnerability we are using.

I only skimmed the first few pages, but got the impression that paper says "GPU architecture is different that modern CPUs, especially around memory layout/protection" and it isn't immediately clear to me where responsibility for any vulnerability lies. Is
it simply not possible to write memory-corruption-proof code for GPUs?

Regardless, I have no problem with issuing CVE IDs for hardware vulnerabilities. I'm just claiming that they are rare, and usually involve low-level software.