[Issue 10225] New: tlso_session_pinning: will crash if digest/keyhash.bv_val is not properly initialized over the lifetime of the function
https://bugs.openldap.org/show_bug.cgi?id=10225
Issue ID: 10225 Summary: tlso_session_pinning: will crash if digest/keyhash.bv_val is not properly initialized over the lifetime of the function Product: OpenLDAP Version: 2.6.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: yaneurabeya@gmail.com Target Milestone: ---
tlso_session_pinning(..) does not initialize the `digest` stack memory before referring to it later on in the function. This can result in a library crash if (for whatever reason) keyhash.bv_val fails to initialize properly on line 1191 [1].
This issue kind of goes hand in hand with bug 10224.
1. https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5f...
https://bugs.openldap.org/show_bug.cgi?id=10225
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #1 from Howard Chu hyc@openldap.org --- No it can't, the digest is a write-only output value. Its initial contents are irrelevant.
https://bugs.openldap.org/show_bug.cgi?id=10225
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=10225
--- Comment #2 from yaneurabeya@gmail.com --- If I submitted a patch to you to either call bzero, memset(.., 0, ..) or use the C99 initializer (= { 0 }), would you take it (and which do you prefer)?
I can give you a whole list of possibilities for what could happen (I was being incredibly non-creative with the rationale at this point after 12+ hours of work).. but at the very least having to mute complaints around uninitialized stack memory from clang scan-build, coverity, etc, helps take away time from more pressing issues. At worst, it helps shift the blame off your code on to bad consumers more easily :) -- plus it avoids someone forking/copy-pasting your code and doing something unwise with it because they don't understand what the code did originally. This is not your problem, but.. after having to deal with a lot of stuff like that from less senior engineers or less C/C++ proficient engineers as an OSS integrator... I'm kind of tired of having to field the complaint "the OS did it" when in fact it's broken middleware, etc.
https://bugs.openldap.org/show_bug.cgi?id=10225
--- Comment #3 from yaneurabeya@gmail.com --- (In reply to yaneurabeya from comment #2)
...
... plus it avoids someone forking/copy-pasting your code and doing something unwise with it because they don't understand what the code did originally.
Plus, with GenAI/LLM use with Codium and Copilot being trained on real world project data (including OSS code), the more good examples that are out there, the better the generated code will be.
I have opinions about GenAI/LLM generated code, but at the very least, less garbage in [via good examples], less garbage out.
-
openldap-its＠openldap.org