There are two concerns here, assuming the attacker can place arbitary values in a dnsProperty attribute over LDAP (eg is a DNS administrator).
This comes from the fact that id is used as the switch value at the C layer
but at the NDR layer the wDataLength value is considered first.
One concern is that a pull/push round-trip could include server memory:
The previous switch_is() behaviour could store the server memory back
into the attribute.
However this pattern of pull/push only happens in ndrdump and fuzzing tools, as
dnsserver_db_do_reset_dword() operates only on the uint32/bitmap union
arms, and fully initialises those.
The other is that a pull of the attacker-supplied value could
cause the server to expose memory.
This would be over the network via DNS or the RPC dnsserver protocols.
However at all times the ndr_pull_struct_blob is passed zeroed memory.
The final concern (which fuzz_ndr_X found) is that in the ndr_size_dnsPropertyData()
the union descriminent is only id.
This has no impact as only zeroed memory is used so there will be a
zero value in all scalars, including data->d_ns_servers.AddrArray.
Therefore the server will not crash processing the attacker-supplied blob
This was known as CVE-2019-14908 before being triaged back to a normal bug.
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X fuzzer.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14206