ClassByteCodeAnnotationFilter doesn't read the constants pool correctly
-----------------------------------------------------------------------

                 Key: MYFACES-2930
                 URL: https://issues.apache.org/jira/browse/MYFACES-2930
             Project: MyFaces Core
          Issue Type: Bug
          Components: General
    Affects Versions: 2.0.3-SNAPSHOT
            Reporter: Christian Kaltepoth
            Priority: Minor
         Attachments: MYFACES-2930.patch

The ClassByteCodeAnnotationFilter used to check classes for annotations by 
reading their bytecode doesn't read the constants pool table correctly.

The current code reads the number of entries from the class file and then reads 
each entry in the pool in a "for" loop. Unfortunately the code fails to process 
entries of the type "CONSTANT_Long" and "CONSTANT_Double" correctly. The Java 
VM spec says:

"All 8-byte constants take up two entries in the constant_pool table of the 
class file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the 
item in the constant_pool table at index n, then the next usable item in the 
pool is located at index n+2. The constant_pool index n+1 must be valid but is 
considered unusable."

From: 
http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#1348

The ClassByteCodeAnnotationFilter doesn't increase the loop counter for these 
entry types. Thus the filter will read bytes outside of the constants pool as 
soon as it finds a double or long constant in the constants pool because it 
will try to read more entries than there actually are.

Please note that this doesn't lead to faulty behavior of the class, because if 
the reader reaches the end of the constants pool, it didn't find any reference 
until then and therefore it is OK to abort scanning and return "false".

Find attached a patch containing a fix for this issue and a small unit test for 
the ClassByteCodeAnnotationFilter. I also added a log statement to default 
block of the switch statement. I guess this wasn't done because the current 
implementation often found bad tag values because of this bug. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to