Regression in change for CVE-2023-5680 that can cause named to crash

Reported to us by an OEM customer who integrates BIND into their own appliance and redistributes:

NOTE: you might find this as a security issue.

We believe we've identified the likely cause of the crash. It's a regression due to the change for CVE-2023-5680. I've added a patch to a unit test for BIND 9.18.24-S1 that can reproduce the crash. I confirmed the crash happened for 9.18.24-S1 and 9.16.48-S1. One straightforward fix is the other patch I've attached to this ticket.

I believe an engineer familiar with the code base can understand how it happens by reading the patch (it has a lot of comments explaining it), so I won't repeat it here. But I'd note one thing: the introduction of the "old IP tree" breaks one critical assumption: when a node's last reference is released, the cleanup makes sure that there is no rdatasetheader that would still have to be cleaned up (such as an expired cache entry). With this, and the fact that whenerver an rdatasetheader makes a node dirty either a node (read or rw) lock is acquired or a node's reference is increased from 0, it was previously guaranteed that overmem purge never frees other entries that the purge code may reference later. Now that the basic assumption is broken, we now have this crash, and there might be other such cases.

I've not tried to reproduce a crash using a named executable, but the unit test indicates it's probably possible to trigger the crash by an external attacker, albeit with some high barriers such as being listed as an "ecs-zone" in the named's configuration. You may want to deal with this case as such.