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