commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CODEC-98) Base64InputStream causes NullPointerException on some input
Date Thu, 25 Mar 2010 17:47:27 GMT

    [ https://issues.apache.org/jira/browse/CODEC-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849800#action_12849800
] 

Gary Gregory commented on CODEC-98:
-----------------------------------

So what should the behavior be on bad input? Garbage in, garbage out, no NPE? It's not complete
garbage out in the case you describe where the end of the transmission is lopped off and causes
an NPE.

> Base64InputStream causes NullPointerException on some input
> -----------------------------------------------------------
>
>                 Key: CODEC-98
>                 URL: https://issues.apache.org/jira/browse/CODEC-98
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: N/A
>            Reporter: Jake Cobb
>            Priority: Critical
>
> Certain (malformed?) input to {{Base64InputStream}} causes a {{NullPointerException}}
in {{Base64.decode}}.
> The exception occurs when {{Base64.decode}} is entered with the following conditions:
> * {{buffer}} is {{null}}
> * {{modulus}} is {{3}} from a previous entry.
> * {{inAvail}} is {{-1}} because {{Base64InputStream.read}} reached EOF on line 150.
> Under these conditions, {{Base64.decode}} reaches line 581 with {{buffer}} still {{null}}
and throws a {{NullPointerException}}.
> Here is some input data that will trigger it:
> {noformat}
> H4sIAAAAAAAAAFvzloG1uIhBKiuxLFGvODW5tCizpFIvODM9LzXFPykrNbmE8//eDC2bq/+ZGJij
> GdiT8/NKUvNKShiYop2iGTiLgQoTS0qLUgsZ6hgYfRh4SjJSE3PS84GmZOSWMAj5gMzVz0nMS9cP
> LinKzEu3rigoLQJpXvNZ/AcbR8gDJgaGigIGBqbLayAuMUxNKdVLTyxJTc7QS07WSyzKLC7JL8lJ
> 1StJLErMKynNSdTLyUxOzStO1fOB0AwQwMjEwOrJwJMbn+mSWFkclpiTmeID4joml2SWpYZk5qaW
> MEj45Bel62flpyTqlwAF9F2A9oBkrMEqnYtSoXyob1hy4z1dShgEIL4oLcnM0Q8N9XQBqubKjYfa
> DjTV1AfoZn2Im/WTk/XhbtaHu1kf6mZ9T5g2YED8BwKgj8WAbtIDuUkP5CY9mJt22FSkZEXf/QkK
> oCIGeVRFSYlA/zsBCZjq//9/PvSP1VvMxMDkxcCe6ZuZk5NZ7MPAnemcUZSfl5+Tn15ZwiCF5n2E
> nDUoDhjVfhrpNABdpI5qWTJYmZ5nsD9Cg0pwSWnSyhOCaYXmAerMoDgsxnAkzG1R+XmpYPXL9Bln
> 1RhJPQarL+dgYNM1MLUyMKioKAYFOCvIBb8vl8qCOFxA4/jAiRIU7HqgYN8zk/n7jNxWfbAXeXJS
> E4tLgOnUKbOk2IuBOzcfzqso6M1QmrzKkedPzcYO3QZu129As4xITlZI6QqYFNhz44v9EkFpCGua
> LmEQdkktS83JL8gF5g4FqBGlIJ+wAI1gKJtZEvTws/j3FluPu4lcr7ra9OfHKXIZNTa4FPd8n33J
> QXPFLte9AZe5uBaJvGrKVl+rbrTaXDZO6NwU7gnHOVgzzsmnGX2Y5GDqrst8wcTear0Ab1yj6PrD
> F977vL/5iUMg773My5qLLK8OVAu6Tz7Xcyjy9Uym02Z/+xY7m85nYo/t4E93FXFKOf9/a3X78neS
> jE5Tu066K3Mdf17m66mbpXN9y34ZZ3ErRobfn+RfzVBIWj0vc82vY7YPvM5eLHHOulV77M6CoB4h
> xb/FjHWHRR+ldb6QmSP1ROGwGs+nx2quwitN7+mIpsRFhU37JPRoZe2ZjiX/70j7CS1tz51YP/3W
> /xfnV2i/4rAoYeAN9nA0NTQqBxYMQcGOAG5
> {noformat}
> Say this is read from file with a {{byte[]}} of size {{1024}} using {{Base64InputStream.read(byte[])}}.
 In the first iteration, all {{1190}} bytes get read into {{buf}}, then it enters {{Base64.setInitialBuffer}}
and assigns the {{byte[1024]}} to {{buffer}} and does a round of decoding.  When it then enters
{{Base64.readResults}} on line {{162}} in {{Base64InputStream}}, it sets {{buffer}} to {{null}},
{{modulus}} has the left-over value {{3}}, and the NPE occurs the next iteration.
> {{Base64InputStream}} could avoid this by returning right away on EOF ({{-1}}), but I
think the real fix needs to happen in {{Base64}} since it this same situation could be created
by direct use.  My guess is either more needs to happen in the body of the {{if}} on line
{{542}} (set {{modulus}} to {{0}}?) or the condition on line {{573}} is flawed and needs adjusting.

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


Mime
View raw message