Ok, let's take this from the top:
1: Defects that cause a server to become unresponsive are bad and must
be repaired as soon as possible.
2: Some #1 class defects are exploitable and require a CVE. As far as
I can tell, this one does not, but you should keep an eye out for the
possibility.
3: The #1 class defect I have found can be triggered in at least two
ways. One requires ipa-replica-install and is hard to reproduce in a
test environment. The other requires ldapdelete and is easy to
reproduce in an isolated VM.
4: The defect is a mismatch between the plugin ABI as implemented by
389-ds, and the behavior the NIS plugin expects.
5: I have found no specification or documentation on said ABI, so I
can only guess what the correct behavior is here.
6: The ABI includes two functions in the plugin: pre_delete and
post_delete.
7: The NIS plugin expects that every call to pre_delete will be
followed by a call to post_delete. It takes a lock in pre_delete and
releases it in post_delete.
8: Under some circumstances 389-ds can call pre_delete but fail to
call post_delete. Because of #5, there is no way to tell if this is
expected behavior, but the NIS plugin clearly does not expect it.
9: My patch ensures that every call to pre_delete is followed by a
corresponding call to post_delete. V1 of the patch also ensures that
every call to post_delete is after a corresponding pre_delete call.
V2 relaxes the second requirement, allowing post_delete calls without
a corresponding pre_delete call because someone expressed worry about
potential regressions.
10: You are refusing to merge my patch because of a doctrinal
objection to the use of ldapdelete in the simple reproducer.