Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8050978

Fix bad field access check in C1 and C2

    Details

    • Subcomponent:
    • Introduced In Version:
      9
    • Resolved In Build:
      b26
    • Verification:
      Verified

      Backports

        Description

        JCK8 test vm/constantpool/accessControl/accessControl004/accessControl00402m3/accessControl00402m3.html fails with -Xbatch -Xcomp due to bad field access check in C1 and C2

        Precondition:
        -------------

        Consider the following class hierarchy:

            A
          / \
         B1 B2

        A declares a field "aa" which both B1 and B2 inherit.

        Despite aa is declared in a super class of B1, methods in B1 might not access the field aa of an object of class B2:

        class B1 extends A {
          m(B2 b2) {
            ...
            x = b2.aa; // !!! Access not allowed
          }
        }

        This is checked by the test mentioned above.


        Problem:
        --------

        ciField::will_link() used by C1 and C2 does the access check using the canonical_holder (which is A in this case) and thus the access erroneously succeeds.


        Fix:
        ----

        In ciField::ciField(), just before the canonical holder is stored into the _holder variable (and which is used by ciField::will_link()) perform an additional access check with the holder declared in the class file. If this check fails, store the declared holder instead and ciField::will_link() will bail out compilation for this field later on. Then, the interpreter will throw an PrivilegedAccessException at runtime.


        Ways to reproduce:
        ------------------

        Run the above JCK test with

        C2 only: -XX:-TieredCompilation -Xbatch -Xcomp

        or

        with C1: -XX:-Inline -Xbatch -Xcomp

        Evaluation
        ---------------

        We consider this fix critical as access control is broken. Fields can be accessed errornously.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  goetz Goetz Lindenmaier
                  Reporter:
                  goetz Goetz Lindenmaier
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  11 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: