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

A potential bug of NPD #863

Closed
ash1852 opened this issue Aug 31, 2022 · 6 comments
Closed

A potential bug of NPD #863

ash1852 opened this issue Aug 31, 2022 · 6 comments

Comments

@ash1852
Copy link

ash1852 commented Aug 31, 2022

Hi, I found a potential null pointer dereference bug in the project source code of libsndfile, and I have shown the execution sequence of the program that may generate the bug on the graph below. The red text illustrates the steps that generate the bug, the red arrows represent the call relationships,the file path can be seen in the blue framed section.

ogg_sync_buffer

Although the code shown is for version 1.0.28 and no longer exist in current version ,bug the same usage of function ogg_sunc_buffer,which is shown below, is still exist in the current version

libsndfile/src/ogg.c

Lines 299 to 300 in 718e305

buffer = (unsigned char *) ogg_sync_buffer (&odata->osync, nb_read) ;
read_ret = psf_fread (buffer, 1, nb_read, psf) ;

would you can help to check if this bug is true?thank you for your effort and patience!

@evpobr
Copy link
Member

evpobr commented Sep 1, 2022

Hi @ash1852 , thanks for report. Yes, it looks like it's a bug. @arthurt , what do you think?

@arthurt
Copy link
Member

arthurt commented Sep 2, 2022

Yes, it is technically a bug.

However, most of the time, unless you are setting RLIMIT_AS to be very low, malloc() never returns null on Linux. This is called memory-overcommiting. You won't know that there isn't any memory until the first time you try and use it, the page faults, looks for some backing memory, and then if you're out of memory, the OOM killer comes around and kills you (or someone else.)

@arthurt
Copy link
Member

arthurt commented Sep 2, 2022

There are probably many instances where we don't check for null malloc return values. Yes, we can fix this, but I fear that there will still be other areas in libsndfile or its libraries that don't check for malloc returning null. Pick your poison, a null pointer dereference caused seg-fault, or an OOM killer triggered death.

@ash1852
Copy link
Author

ash1852 commented Sep 2, 2022

There are probably many instances where we don't check for null malloc return values. Yes, we can fix this, but I fear that there will still be other areas in libsndfile or its libraries that don't check for malloc returning null. Pick your poison, a null pointer dereference caused seg-fault, or an OOM killer triggered death.

According to the results of our analysis tool (although we set a timeout for analysis and some heuristic pruning work), this is the only NPD that exists explicitly between libsndfile and other library due to absence of malloc-fail check

@arthurt
Copy link
Member

arthurt commented Sep 2, 2022

We can get a MR up to fix this soon... (it's a long weekend for me :) ).

@arthurt
Copy link
Member

arthurt commented Dec 13, 2022

Thanks for the report. Closing as fixed.

@arthurt arthurt closed this as completed Dec 13, 2022
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

3 participants