SELinux somehow interferes with nbd-client devices, causing a protocol error that fails all reads to the nbd device, but only when the nbd device contains an mdadm software RAID member. No SELinux denials are logged and there are no SELinux messages of any kind in dmesg or journalctl during or around the issue, making this problem difficult/subtle to diagnose, but "setenforce 0" prevents the issue from occurring.

Reproducible: Always

Steps to Reproduce:
Run the following sequence of commands on any Fedora host (tested on a fresh install of 41):

dnf install nbd
truncate -s 256M /tmp/testfile
nbd-server localhost:10809 /tmp/testfile
nbd-client localhost
mdadm --create -l 1 -n 2 /dev/md/testarray /dev/nbd0 missing
mdadm --stop /dev/md/testarray
nbd-client -d /dev/nbd0
nbd-client localhost

Actual Results:  
After the mdadm --create command, the array appears to function normally and is readable. However, after disconnecting, all future attempts to use the nbd device fail, even if mdadm is not used - the fact that the device contains an mdadm signature is apparently enough to trigger the problem, even if the array is not used.

After the final command above, the following appears in dmesg:

block nbd0: Send control failed (result -13)
block nbd0: Request send failed, requeueing
block nbd0: Receive control failed (result -32)

(for the full set of dmesg errors, see attachments)


Expected Results:  
Either:

- The mdadm array reassembles automatically after udev is triggered by the block device appearing, and the mdadm array is then readable as usual.

or

- The block device becomes available, and subsequent reads (such as with blkid, or any other utility that issues basic block device read operations) succeed, and the mdadm device can be assembled and started manually.

or

- SELinux logs information about what operation it is denying before causing the nbd device to fail, and also, if SELinux is behaving correctly by preventing the combination of mdadm and nbd, it should be consistent and also prevent the device from being started after mdadm first creates it.

It is important to note that the problem is definitely with the nbd-client component, and not the server. The behaviour described above happens even if the nbd-server is running on an entirely different machine, under a different Linux distribution (when I encountered this bug, I was serving from an Arch Linux live ISO, and I initially assumed the problem was a version/protocol mismatch until I got the test case down to the minimal local case above).

Also, if a Fedora machine is the nbd-server, a different machine running a different distribution (or a different Fedora machine on which SELinux is disabled) is able to use the served device with mdadm without problems.

I have not noticed any other problems with nbd-client when using other block device layers on nbd devices -- e.g. LVM appears to function normally. I have not tried LVM RAID, but  creating an mdadm array on top of an LVM logical volume also triggers this bug.

I have not tested this with nbdkit or qemu-nbd.