Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible Null Pointer Dereference in SExpression.java #1888

Open
Sawraz-OpenRef opened this issue Oct 29, 2024 · 1 comment
Open

Possible Null Pointer Dereference in SExpression.java #1888

Sawraz-OpenRef opened this issue Oct 29, 2024 · 1 comment
Assignees

Comments

@Sawraz-OpenRef
Copy link

Sawraz-OpenRef commented Oct 29, 2024

What happended?

In file: SExpression.java, there is a potential case of null pointer dereference. In method parse(), there is a call to parseExpression(), passing parameter SExpression to be null.

    public static SExpression parse(InputStream _src, int maxDepth)
        throws IOException
    {
        return parseExpression(_src, null, new ByteArrayOutputStream(), maxDepth);
    }
    
    private static SExpression parseExpression(InputStream src, SExpression expr, ByteArrayOutputStream accumulator, int maxDepth)
    throws IOException
    {
        ...........
        ...........
    }

But this null case isn't handled in parseExpression(), and addValue() method is invoked on this null object, which will cause NullPointerException.

It is not immediately clear whether consumeUntilSkipCRorLF(), will always return -1 or will always return ( first before entering any other condition when expr is set to null. If that is indeed the case, you may choose to ignore this issue.

Sponsorship and Support:

This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed - to improve global software supply chain security.

The bug is found by running the iCR tool by OpenRefactory, Inc. and then manually triaging the results.

@ligefeiBouncycastle ligefeiBouncycastle self-assigned this Oct 29, 2024
@ligefeiBouncycastle
Copy link
Collaborator

Thank you for identifying this potential issue. I’m curious how a valid test case might reach line 140, as the function appears to rely on recursive calls to reach that line. If possible, please provide a valid test case—your assistance is much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants