(In reply to comment #1)
> This indicates the kernel is leaking a file descriptor.
How does it indicate this?
Please provide more details and logging information.
You probably need to enable auditing to find the pathnames etc.

(In reply to comment #2)
The audit messages show denials on:
- an open file descriptor labeled with the kernel's domain (kernel_t) that
refers to a file named "hda7", and
- the "hda7" file referenced by that descriptor, labeled with the
fixed_disk_device_t type and the blk_file (block device file) class.
This implies that a kernel thread (or subsequent usermode helper run by a kernel
thread without performing a domain transition, although such helpers typically
have their own domains, at least under strict) has opened a descriptor to that
device and failed to close it, such that all descendants end up trying to
inherit it and run into the SELinux denials (which would close the descriptor
and replace it with a reference to the null device if in enforcing mode).

I'd suggest re-assigning component to lvm, as I think that this is just a
descriptor leak by it. From the various reports, it sounds like lvm is opening
the swap device and never closing it (or marking it close-on-exec), so all
descendants end up inheriting the descriptor and SELinux correctly stomps on it.