On Wed, 15 Jul 2026 02:54:11 GMT, David CARLIER <[email protected]> wrote:
>> Found while auditing the JVMTI local-variable accessors. >> >> `VM_BaseGetOrSetLocal` bounds-checks the requested slot before touching the >> frame's `StackValueCollection`. For a `long`/`double` the value spans two >> slots, so the check adds an `extra_slot` of 1: `_index + extra_slot >= >> method->max_locals()`. When an agent passes `slot == INT_MAX`, `_index + >> extra_slot` signed-overflows to `INT_MIN`, which is below `max_locals()`, so >> the guard is bypassed and we go on to index `locals->at(INT_MAX)` — out of >> bounds. That is an assertion failure in fastdebug and a SIGSEGV or silent >> corruption in product. >> >> Doing the arithmetic on the other side (`_index >= method->max_locals() - >> extra_slot`) avoids the overflow. The same check appears in both >> `check_slot_type_lvt` and `check_slot_type_no_lvt`, so both are fixed. >> >> Additional testing: >> - [x] Linux x86_64 server fastdebug, `serviceability/jvmti/GetLocalVariable` >> - [ ] Regular testing pipelines >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > David CARLIER has updated the pull request incrementally with one additional > commit since the last revision: > > address feedback @devnexen I do not see you in the list of the openJDK developers. Do you have an openJDK name? Just wanted to double check this before sponsoring the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31772#issuecomment-4979190286
