Comment 12 for bug 1667016

I believe this happens because, based on the following audit log,

AVC apparmor="AUDIT" operation="exec" info="ix fallback" profile="lxd-x_</var/snap/lxd/common/lxd>" name="/usr/bin/tcpdump" pid=154814 comm="bash" requested_mask="x" fsuid=1000000 ouid=1000000 target="lxd-x_</var/snap/lxd/common/lxd>"

lxd opens the file descriptor for stdout and stderr, and when tcpdump is executed, the container profile transitions to the tcpdump profile. AppArmor then reevaluates all opened fds, to check if the current task still has access to it. More implementation details here:
https://gitlab.com/apparmor/apparmor-kernel/-/blob/apparmor-next/security/apparmor/file.c#L638
https://gitlab.com/apparmor/apparmor-kernel/-/blob/apparmor-next/security/apparmor/file.c#L597

Since the policy for tcpdump did not have explicit access to stdout/stderr, they are blocked from reading/writing.
This does not happen in a normal host or VM because whichever program executes tcpdump (bash for example), is usually unconfined, so the fds are not reevaluated.