Thanks.
I notice your first write() is on fd 3 while the 2nd is on stdout (while
for me the first 2 are on fd 3, which in my case is the LDAPS socket).
For the issue to be reproduced, we need the client to be paused after
having send the TLS "client hello".
The first time the breakpoint is hit, y
lincvz:
> Thank you for the patch and your investigations. In the next few days, I
> cannot install the patched package on my production machines. I'll let you
> know when I can.
Thanks.
Can you reproduce a similar issue with the modus operandi (using gdb) I
describe above?
(Note that while it
> This is a valid issue, but are we certain it's the same one? The
> reporter talked about sched_yield and their backtraces included several
> threads of back_monitor waiting on some kind of lock.
You're right. It may be a different issue (though possibly linked to the
same root cause). In my case
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield sysca
> It can be reproduced by running on a client:
>
> gdb --args ldapsearch -H ldaps://ldap.example.com -x
>
> Then in gdb:
>
> break write
> run
> continue
I can no longer reproduce it after I rebuild and install the libldap
package with
https://github.com/openldap/openldap/commit/4c1ab16ade18a25
Yes,
https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa410aa7d1503
can't be directly applied there. There have been other changes in
between in that section including changes in API, so it would take more
effort to backport that fix.
--
You received this bug notification be
cherry picking
https://github.com/openldap/openldap/commit/4c1ab16ade18a253dd81df7e6eced4d920ac6a8e
should fix this particular issue but reintroduce
https://bugs.openldap.org/show_bug.cgi?id=8650.
It may be necessary to pick
https://github.com/openldap/openldap/commit/735e1ab14bb055344b4e767a216aa
The important backtrace in there is the one from thread 11:
#0 0x7fb288428474 in read () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x7fb2890c4518 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
No symbol table info available.
#2 0x7fb2878
See with just running ldapsearch after upgrade to 16.04:
```
# repeat 10 ldapsearch -x > /dev/null
# tail /var/log/auth.log
Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free
Apr 19 14:53:01 hostname ldapsearch: DIGEST-MD5 common mech free
Apr 19 14:53:01 hostname ldapsearch: DIGEST-
correction on my previous comment:
My point "1" is only true on Debian and derivatives. bash does drop its
privilege when setuid and called as sh without -p just like when not
called as sh, but Debian's bash package has a patch that disables that
dropping of privileges when called as sh.
https://
There are several incorrect statements in the initial report and the
linked CVE.
1. bash doesn't drop its privilege when setuid when called as sh. It
only does so when called as bash and without the -p option. It does
however go into a mode where it does not trust its environment as much
as when i
11 matches
Mail list logo
