https://bugs.openldap.org/show_bug.cgi?id=9936
Issue ID: 9936
Summary: slapd attempting free on address which was not
malloced
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kimjuhi96(a)snu.ac.kr
Target Milestone: ---
I get invalid free running this on the latest openldap from git, built with
CFLAGS="-fsanitize=address" using clang 15.
Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912.
./servers/slapd/slapd -T c -s1 -s1
Stopped reason: SIGABRT
__GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
gdb-peda$ bt
#0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff78ca859 in __GI_abort () at abort.c:79
#2 0x00005555556eb04f in __sanitizer::Abort ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143
#3 0x00005555556e8aac in __sanitizer::Die ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58
#4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport
(this=0x7fffffffbe7e, __in_chrg=<optimized out>)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192
#5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>,
free_stack=0x7fffffffca90)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199
#6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359)
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53
#7 0x0000555555d3efe2 in ber_memfree_x ()
#8 0x0000555555847d33 in ch_free ()
#9 0x0000555555a31178 in slap_tool_init ()
#10 0x0000555555a2e54d in slapcat ()
#11 0x000055555570901f in main ()
#12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>,
argc=0x5, argv=0x7fffffffdfc8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffdfb8)
at ../csu/libc-start.c:308
#13 0x000055555561011e in _start ()
at
/home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397
gdb-peda$
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9888
Issue ID: 9888
Summary: When using cn=config replication, schema updates can
corrupt the index database(s)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Today I pushed a schema update out to the config node that holds schema that is
replicated to the providers and consumers. Post schema update, 2/11 servers
crashed in the mdb online indexing function. I fixed this by slapcat the db
and slapadd the db. This is important because it was later revealed that on
the 9/11 servers that did not crash or have their database reloaded, ldapsearch
would return the wrong attribute names for some attribute:value pairs in the
database, which caused mayhem in downstream systems and caused replication
issues between the nodes. The 2 nodes that were reloaded immediately after the
schema change had the only "good" copies of the database left.
To give an example, say an entry was something like:
dn: uid=joe,ou=people,dc=example,dc=com
uid: joe
sn: smith
cn: joe smith
givenName: joe
After the change, the broken servers could return something like:
dn: uid=joe,ou=people,dc=example,dc=com
uid: joe
posixGroup: smith
cn: joe smith
givenName joe
It's not clear how deeply this bug ran in the database. It for sure affected 2
attributes used by the person objectClass. Both of the "replacement"
attributes were not valid attributes for the person objectClasses in use.
Maybe related to the changes in ITS#9858?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9863
Issue ID: 9863
Summary: lastbind configuration fails to honor chaining
configuration
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In an environment where consumers are configured to chain writes up to the
providers, lastbind configuration fails to honor this which is generally what
one would expect. This causes mismatches between the providers and consumers
in regards to the database state. Additionally it introduces random serverIDs
into the database.
In my case, the providers have serverIDs 10, 20, 30 configured but the consumer
is generating serverID 1 for the entryCSN.
Expectation: consumer does not generate *any* entryCSN value and instead
forwards the write op to the provider.
Log from consumer:
slap_get_csn: conn=1069 op=0 generated new
csn=20220610180137.644625Z#000000#001#000000 manage=1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9735
Issue ID: 9735
Summary: [PATCH] try hard to find free space if database cannot
grow
Product: LMDB
Version: 0.9.24
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: libor.peltan(a)nic.cz
Target Milestone: ---
Created attachment 851
--> https://bugs.openldap.org/attachment.cgi?id=851&action=edit
Patch fixing the issue "try hard to find free space if database cannot grow"
Note:
- the issue is the same in version 0.9.70 (git)
Situation:
- the database had already grown to its limit (mapsize) in the past
- overflow pages are used heavily as stored values are usually several pages
long
- free space got fragmented
Problem:
- attempt to insert new value results in MDB_MAP_FULL despite there is free
space available
Cause: there is a heursitic in mdb_page_alloc() that gives up searching for
free space chunk if this would take too much time. This is useful when the
database can still grow, as it balances performance with space usage. However,
if the database can no longer grow, it prevents inserting new values.
Solution: detect early on in mdb_page_alloc() if the database can grow, and if
not, let it try hard to search for free space.
Patch: attached
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9471
Issue ID: 9471
Summary: Add RBAC overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its RBAC overlay to core
The slapo-rbac overlay is an implementation of the ANSI INCITS 359 Role-Based
Access Control (RBAC) Core.
When instantiated, it intercepts, decodes and enforces specific RBAC policies
per the Apache Fortress RBAC data formats.
The overlay provides a set of extended operations.
They include session create/delete, checkAccess, addActiveRole, dropActiveRole
and sessionRoles.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9472
Issue ID: 9472
Summary: Add datamorph overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its datamorph overlay to core
The datamorph overlay to slapd allows attributes with a few predefined values
to be saved more space-efficiently as well as signed or unsigned integer
attributes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9473
Issue ID: 9473
Summary: Add variant overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its variant overlay to OpenLDAP core
The variant overlay to slapd allows attributes/values to be shared between
several entries. In some ways this is similar to slapo-collect with the
exception that the source and target attributes can be different.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9993
Issue ID: 9993
Summary: Potential race condition in back-mdb online indexer
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the online indexer completes, it should mutex-protect its resetting of the
indexing flags.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9995
Issue ID: 9995
Summary: Potential memory leak in clients/tools/ldapdelete.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapdelete.c line 384.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9989
Issue ID: 9989
Summary: «make clean» shall not delete
libraries/libldap/ldap.pc and
libraries/liblber/lber.pc
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
«./configure» and «./config.status» do create ./libraries/libldap/ldap.pc,
./libraries/liblber/lber.pc, while «make clean» deletes both .pc files.
«make install» fails, if ./libraries/libldap/ldap.pc or
./libraries/liblber/lber.pc are missing.
«./configure && make clean && make depend && make install» is a valid workflow
for many other (autoconf/automake based) projects.
./libraries/libldap/ldap.pc and ./libraries/liblber/lber.pc shall be deleted by
«make distclean», and kept by «make clean».
See also https://www.gnu.org/prep/standards/html_node/Standard-Targets.html for
the idea behind «make clean» vs «make distclean».
--
You are receiving this mail because:
You are on the CC list for the issue.