User: Password:
|
|
Subscribe / Log in / New account

On the importance of return codes

On the importance of return codes

Posted Dec 3, 2009 3:13 UTC (Thu) by jimparis (subscriber, #38647)
Parent article: On the importance of return codes

It seems strange that unsetenv() thought the environment was corrupt and couldn't handle it, while something (getenv()?) was still able to read the bad LD_PRELOAD variable later.


(Log in to post comments)

On the importance of return codes

Posted Dec 3, 2009 9:57 UTC (Thu) by hppnq (guest, #14462) [Link]

That's because getenv(), unlike unsetenv(), does not always check for a corrupt environment: it simply loops over the entire environment when the program brings its own. So getenv() skips environ[0] and reads LD_PRELOAD from environ[1], while unsetenv() complains about the corrupted environ[0].

It seems only a relatively recent change to unsetenv() introduced a non-void return value, and that the loader code was not updated at the same time.

On the importance of return codes

Posted Dec 3, 2009 10:27 UTC (Thu) by epa (subscriber, #39769) [Link]

It seems only a relatively recent change to unsetenv() introduced a non-void return value, and that the loader code was not updated at the same time.
I wonder whether linting the whole source tree with some kind of static analyser to warn about ignored return values would have caught this.

On the importance of return codes

Posted Dec 3, 2009 13:12 UTC (Thu) by NAR (subscriber, #1313) [Link]

I guess some static analyser could have warned about this. But I also guess that that warning would have been buried deep under heaps of false alarms. The Linux kernel NULL-pointer vulnerabilities were detected by the Stanford checker (if I remember correctly), it's just nobody cared to wade through all that stuff.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds