Loop devices can bypass Linux capability checks via sysfs

A loop device can be pointed at procfs or sysfs and then read or write kernel interfaces that the caller is not allowed to touch, because the loop worker runs with kernel credentials. Christian Brauner has posted a request-for-comments series that would refuse regular files on pseudo filesystems as backing storage for loop and several other kernel consumers.

Loop accepts any regular file with the usual read method, and any file that can also be written, as a disk image. That is not limited to real files. Brauner showed that /proc/kcore attaches read-only as a loop device the size of the kernel's virtual address space, 64 PiB with five-level paging, and that sysfs attributes attach as 4096-byte read-write devices. Writing a block to a loop device backed by the transparent hugepage control file changes that setting.

The abuse is a credential mismatch. Many sysfs handlers enforce access by calling capable() when the file is read or written. Setting up a loop device needs no capabilities, only access to the device nodes, so those checks run against the loop worker rather than the task that opened the file.

On a current release candidate, a uid 0 process with an empty capability set could not kill a process owned by uid 1000, and a direct write to the hardware page-offline interface failed. Putting that write-only file behind a loop device and writing a block containing a page address made the kernel report a memory failure and kill the victim. The same pattern reaches radio soft-block controls, the reboot mode, md array attributes, SCSI disk settings, and DMI firmware entries. An unprivileged container handed a loop device could also change a network device's GRO flush timeout, which normally requires CAP_NET_ADMIN in the initial user namespace.

The fix marks pseudo filesystems and rejects their regular files as storage, looking through overlayfs so a sysfs file hidden under a lower layer is still caught. Device nodes on filesystems such as devpts are left alone. The same refusal would apply to zloop zone files, the NVMe target's file backend, the SCSI target's file backend, FUSE backing files, USB gadget mass-storage LUNs, and file-backed erofs images. Self-tests cover procfs and sysfs loop attachments, an overlay of sysfs, a gadget LUN, and an erofs source, and check that a memfd and another loop device still work.

An automated review of the SCSI target change flagged one leftover path: when data-integrity protection is enabled, the companion protection file is opened by name without the same check, so a symlink or bind mount onto procfs or sysfs could still be read and written with kernel credentials.