https://bugs.openldap.org/show_bug.cgi?id=10077
Issue ID: 10077 Summary: Integer overflow in util-int.c Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: michal.pura@gmail.com Target Milestone: ---
Created attachment 971 --> https://bugs.openldap.org/attachment.cgi?id=971&action=edit the fix proposal for ldap_pvt_gettimensec() function
Hello, I found the issue with contextCNS generating process which cause that its format is invalid (minus sign in nanoseconds filed).
Example: "generated new csn=20230630080704.-489933Z#000000#000#000000"
The bug can introduce the minus sign in the contextCSN what could have an impact in replication process, backup restoring etc. Everywhere when the format of contextCSN is checked before processing it.
According to the source code and reference documents the contextCSN nanoseconds filed should have the value from range: 000000-999999.
https://www.openldap.org/faq/data/cache/1145.html
The problem is in the function ldap_pvt_gettimensec() in util-int.c file. For example in line:
count.QuadPart += (10 * BILLION);
The value of (10 * BILLION) will be treated as 32-bit value by compilator and will cause the integer overflow. Then the random value is added to count.QuadPart what in some specific cases can produce the negative value which is returned from the function. At the end the value is passed to the function ldap_pvt_csnstr() so the contextCSN is wrongly generated (with minus sign).
There is missing 'LL' qualifier, code should looks like this:
count.QuadPart += (10LL * BILLION);
I also suggest to change the type of _ldap_pvt_gt_offset variable from int to long long.
In attachment you will find fix proposal as there are more places in the function where changes are required.
https://bugs.openldap.org/show_bug.cgi?id=10077
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.5.17 Assignee|bugs@openldap.org |hyc@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10077
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS
--- Comment #1 from Howard Chu hyc@openldap.org --- https://git.openldap.org/openldap/openldap/-/merge_requests/647
Never was able to reproduce it locally. gcc would warn if the constant didn't fit but never emitted any such warning. Perhaps this was only broken in MSVC.
https://bugs.openldap.org/show_bug.cgi?id=10077
--- Comment #2 from michal.pura@gmail.com --- Yes, the problem has been seen on MSVC compiler, but shouldn't be code resistance for such bug no matter where it was compiled ?
https://bugs.openldap.org/show_bug.cgi?id=10077
--- Comment #3 from michal.pura@gmail.com --- Created attachment 975 --> https://bugs.openldap.org/attachment.cgi?id=975&action=edit msvc negative nsec value
The situation happened on the MSVC compiler (Compiler Version 19.29.30147). I also cannot reproduce the problem on GCC, but I suggest to make code more resilience for any compiler.
https://bugs.openldap.org/show_bug.cgi?id=10077
--- Comment #4 from Howard Chu hyc@openldap.org --- Are you saying that the problem still exists with the patch I linked above?
Still unable to reproduce it here.
https://bugs.openldap.org/show_bug.cgi?id=10077
--- Comment #5 from Howard Chu hyc@openldap.org --- (In reply to michal.pura from comment #2)
Yes, the problem has been seen on MSVC compiler, but shouldn't be code resistance for such bug no matter where it was compiled ?
We explicitly do not support MSVC.
https://bugs.openldap.org/show_bug.cgi?id=10077
--- Comment #6 from michal.pura@gmail.com --- Sorry I didn't see the merge link. The provided solution is ok.
https://bugs.openldap.org/show_bug.cgi?id=10077
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|IN_PROGRESS |RESOLVED
--- Comment #7 from Howard Chu hyc@openldap.org --- This patch was insufficient, and surfaced another problem (ITS#10100). Closing this as a dup of ITS#10100.
*** This issue has been marked as a duplicate of issue 10100 ***
https://bugs.openldap.org/show_bug.cgi?id=10077
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED