There’s a bunch of stuff going on here.
The idea behind zerocopy is to allow userspace to directly map the actual memory buffer used for talking to the USB controller. So the USB controller fills that memory, and then userspace can directly use the data, without the kernel needing to copy the data around further.
There was a cache coherency or mapping problem of some type (I’m not familiar with the exact mechanics) that meant that in older kernels, the userspace zerocopy buffer didn’t actually point at the right place. So userspace would see garbage data, not the expected USB data. librtlsdr built with ENABLE_ZEROCOPY=ON tests for this and disables zerocopy if that kernel bug is present. This is what happens on the 4.x kernels on a Pi.
Separately (I’m not sure if it had the same cause or not) there was a kernel bug that meant on some architectures (maybe aarch64? I forget), trying to access a zerocopy buffer at all resulted in a SIGKILL. librtlsdr would trigger this while trying to test for the previous zerocopy bug. I think this was, again, a mapping problem where the mapping pointed to the wrong place, perhaps outside physical memory. The existence of this problem lead to librtlsdr changing the default to ENABLE_ZEROCOPY=OFF
Finally, with both kernel bugs fixed and ENABLE_ZEROCOPY=ON (this is the situation on Raspbian with a 5.x kernel), zerocopy is actually used. But it performs terribly; if I had to guess, given the previous cache coherency issues, this might be due to something like having the memory region underlying the zerocopy buffers set to uncacheable.
AFAIK userspace is not doing anything really wrong here, it’s just that the zerocopy performance is bad.
dump1090 can probably avoid the problem by ensuring that it only reads from the zerocopy buffer, and doesn’t try to do conversion work in-place there.