JDK-8323436 : 4.4.10: Restrict invokedynamic constant names
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 21,22,23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-01-10
  • Updated: 2024-06-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 24
24Unresolved
Related Reports
Relates :  
JDK-8322655 - Allow NameAndType constants with special method names
Description
A CONSTANT_InvokeDynamic references a CONSTANT_NameAndType. It is required, via format checking, that "the indicated descriptor must be a method descriptor". However, there is no stated restriction on the *name* portion of the NameAndType.

Because 'invokedynamic' is meant to mimic a method call, a reasonable expectation is that the rules governing the NameAndType of a Methodref from an invokestatic would apply here: the name must be a valid *method name* (4.2.2), and must not be '<clinit>' or '<init>' (in other words, the name must not make any use of '<' or '>').

I don't believe JVMS currently asserts any restrictions about invalid method names (e.g., '<foo>' or 'x>y'); it does prohibit the names '<clinit>' and '<init>' on verification of an 'invokedynamic' instruction.

In JDK 13, Hotspot allows a method named <init> if the descriptor is ()V, subsequently rejecting the method name at verification time. Since we already know this NameAndType is intended to be used by an invokedynamic, it doesn't make much sense to defer half of the check. (Compare the validation of MethodHandle structures (4.4.8), which also enforces verification-style constraints during format checking on use of the name <init>.)

To simplify, I propose enforcing a format check for CONSTANT_InvokeDynamic that the name be a valid, non-special method name.
Comments
Proposed change to 4.10.1.9 for 'invokedynamic' (these checks are already enforced by format checking): An invokedynamic instruction is type safe iff all of the following are true: - Its first operand, CP, refers to a constant pool entry denoting an dynamic call site ~~with name CallSiteName~~ with descriptor Descriptor. - ~~CallSiteName is not <init>.~~ - ~~CallSiteName is not <clinit>.~~ - One can validly replace types matching the argument types given in Descriptor on the incoming operand stack with the return type given in Descriptor, yielding the outgoing type state. instructionIsTypeSafe(invokedynamic(CP,0,0), Environment, _Offset, StackFrame, NextStackFrame, ExceptionStackFrame) :- ~~CP = dmethod(CallSiteName, Descriptor),~~ **CP = dmethod(_CallSiteName, Descriptor),** ~~CallSiteName \= '`<init>`',~~ ~~CallSiteName \= '`<clinit>`',~~ parseMethodDescriptor(Descriptor, OperandArgList, ReturnType), reverse(OperandArgList, StackArgList), validTypeTransition(Environment, StackArgList, ReturnType, StackFrame, NextStackFrame), exceptionStackFrame(StackFrame, ExceptionStackFrame).
12-01-2024
Proposed change to 4.4.10: In a CONSTANT_Dynamic_info structure, the indicated descriptor must be a field descriptor (4.3.2). In a CONSTANT_InvokeDynamic_info structure, **the indicated name must be a valid method name (4.2.2) and must not be <clinit> or <init>**. ~~the~~ **The** indicated descriptor must be a method descriptor (4.3.3).
10-01-2024