Linux: page->_refcount overflow via FUSE with ~140GiB RAM usage
Tested on:
Debian Buster
distro kernel "4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22)"
KVM guest with 160000MiB RAM
A while back, there was some discussion about possible overflows of the
`mapcount` in `struct page`, started by Daniel Micay.
See the following threads:
https://lore.kernel.org/lkml/CAG48ez3R7XL8MX_sjff1FFYuARX_58wA_=ACbv2im-XJKR8tvA@mail.gmail.com/t/#u
"Re: [PATCH v5 07/27] mm/mmap: Create a guard area between VMAs"
Sent by me, forwarding Daniel Micay's concern about overflows of `mapcount`.
https://lore.kernel.org/lkml/20180208021112.GB14918@bombadil.infradead.org/T/
"[RFC] Warn the user when they could overflow mapcount"
from Matthew Wilcox <willy@infradead.org>
I have now noticed that the `_refcount` has a similar problem, and it is
possible to overflow it on a machine with ~140GiB of RAM (or probably also less
on kernels that have commit 5da784cce4308 ("fuse: add max_pages to init_out"),
but that's very recent, it landed in 4.20).
A FUSE request can, by default (and on kernels <4.20 always), contain up to
FUSE_DEFAULT_MAX_PAGES_PER_REQ==32 (on older kernels FUSE_MAX_PAGES_PER_REQ==32)
page references. (>=4.20 allows the user to bump that limit up to
FUSE_MAX_MAX_PAGES==256.) The page references in a FUSE request are stored as
an array whose elements are concatenations of a `struct page *` and a
`struct fuse_page_desc` (8 bytes, containing length and offset inside the page).
This means that each page reference consumes 16 bytes, so to overflow the
32-bit `_refcount` of a page, pow(2,32)*16B=64GiB of kernel memory are needed as
storage for such references allocated with fuse_req_pages_alloc(). All other
overhead is at least per-FUSE-request and distributed over
FUSE_DEFAULT_MAX_PAGES_PER_REQ==32 references.
FUSE does permit read/write operations that operate on more pages than the
maximum FUSE request page count; in this case, if direct I/O is used,
fuse_direct_io() splits the operation into multiple requests. This means that
the only limits at the VFS layer are MAX_RW_COUNT==0x7ffff000 and
UIO_MAXIOV==0x400.
This means that it is possible to create 0x7ffff references to a page that can
be freely mapped in userspace as follows:
- Set up a virtual memory area that contains 0x200 consecutive mappings of the
same page.
- Create an array of UIO_MAXIOV==0x400 identical IO vectors that point to the
area containing the 0x200 mappings.
- Open a FUSE-backed file with O_DIRECT. (This file should ***NOT*** be served
as FOPEN_DIRECT_IO by the FUSE filesystem, that prevents AIO from working
AFAICS! That probably counts as a bug if I'm right...)
- Use the UIO_MAXIOV==0x400 IO vectors for a read operation on the file.
- Let the FUSE filesystem leave the read requests pending.
By sending 0x2000 such read operations, the _refcount can be brought close to
overflow.
(Technically, you could play games with unaligned addresses and such to increase
the number of references per read operation a bit further.)
In order to avoid needing one client-side userspace thread per read operation,
it is possible to use AIO. AIO is able to send read operations that will be
processed asynchronously by FUSE; however, FUSE limits the number of resulting
FUSE requests ***per FUSE filesystem*** to a variable number that depends on the
amount of physical memory the system has (see sanitize_global_limit(); the limit
is the amount of RAM multiplied with 2^-13). Since this limit is per-filesystem,
as long as a single filesystem operation's FUSE requests fit in the limit,
an attacker can distribute the filesystem operations across multiple FUSE
filesystems.
AIO also imposes a global limit on the number of pending operations.
The official limit for pending AIO operations across the system is
aio_max_nr==0x10000; however, as a comment in fs/aio.c explains,
the real limit is significantly higher, and up to 0x10000 *pages* of
io_event structs (minus the overhead of `struct aio_ring`)
can be used (see aio_setup_ring()); this means that the real limit is
0x10000*((0x1000-128)/32)==0x7c0000 operations.
But since the bug can be triggered with ~0x2000 parallel pread operations, that
doesn't matter here anyway.
I am attaching a crash PoC.
First, to make it possible to call dump_page() from userspace for easier
debugging:
- Unpack dump_page_dev.tar.
- Build the kernel module in dump_page_dev/ with "make".
- Load the built kernel module with "sudo insmod dump_page_dev.ko".
For the actual PoC:
- Ensure that there is no distro-specific sysctl that prevents unprivileged
namespace creation (on Debian:
"echo 1 > /proc/sys/kernel/unprivileged_userns_clone"). This is necessary
to be able to create a mount namespace and mount as many FUSE filesystems as
we want in there; the SUID fusermount helper imposes a limit of 1000 FUSE
mounts.
- Unpack fuse_aio.tar.
- Build the PoC with ./compile.sh.
- Launch a new graphical terminal with multiple tabs in a new mount namespace,
using a command like
`unshare -mUrp --mount-proc --fork xfce4-terminal --disable-server`.
- Inside the namespace, run ./fuse_aio to mount 0x2000 FUSE filesystems.
- In a second terminal tab inside the namespace, run ./aio_reader to trigger
the bug.
- Wait and watch `sudo dmesg -w`.
You should see debug output like this in dmesg:
[ 304.782310] fuse init (API version 7.27)
[ 309.607367] mmap: aio_reader (10371) uses deprecated remap_file_pages() syscall. See Documentation/vm/remap_file_pages.rst.
[ 309.631150] dump_page: ---------- STARTING DUMP ----------
[ 309.631154] dump_page: DUMP MARKER: 0x0
[ 309.631158] page:fffff7bad9e04fc0 count:8194 mapcount:8192 mapping:ffffa0f08abdb358 index:0x0
[ 309.631162] flags: 0x17fffc00004007c(referenced|uptodate|dirty|lru|active|swapbacked)
[ 309.631165] raw: 017fffc00004007c fffff7bad9e049c8 ffffa0f0a04e0c10 ffffa0f08abdb358
[ 309.631167] raw: 0000000000000000 0000000000000000 0000200200001fff ffffa0f0a036e000
[ 309.631169] page dumped because: dump requested via ioctl
[ 309.631170] page->mem_cgroup:ffffa0f0a036e000
[ 309.631171] dump_page: ========== END OF DUMP ==========
[ 309.667063] dump_page: ---------- STARTING DUMP ----------
[ 309.667067] dump_page: DUMP MARKER: 0x1
[ 309.667070] page:fffff7bad9e04fc0 count:532481 mapcount:8192 mapping:ffffa0f08abdb358 index:0x0
[ 309.667074] flags: 0x17fffc00004007c(referenced|uptodate|dirty|lru|active|swapbacked)
[ 309.667078] raw: 017fffc00004007c fffff7bad9e049c8 fffff7bad9d09a08 ffffa0f08abdb358
[ 309.667080] raw: 0000000000000000 0000000000000000 0008200100001fff ffffa0f0a036e000
[ 309.667081] page dumped because: dump requested via ioctl
[ 309.667082] page->mem_cgroup:ffffa0f0a036e000
[ 309.667083] dump_page: ========== END OF DUMP ==========
[ 423.507289] dump_page: ---------- STARTING DUMP ----------
[ 423.507293] dump_page: DUMP MARKER: 0x2
[ 423.507296] page:fffff7bad9e04fc0 count:-2147479550 mapcount:8192 mapping:ffffa0f08abdb358 index:0x0
[ 423.507299] flags: 0x17fffc00004007c(referenced|uptodate|dirty|lru|active|swapbacked)
[ 423.507302] raw: 017fffc00004007c fffff7bad9e049c8 fffff7bad9d09a08 ffffa0f08abdb358
[ 423.507303] raw: 0000000000000000 0000000000000000 8000100200001fff ffffa0f0a036e000
[ 423.507304] page dumped because: dump requested via ioctl
[ 423.507305] page->mem_cgroup:ffffa0f0a036e000
[ 423.507306] dump_page: ========== END OF DUMP ==========
[ 608.388324] dump_page: ---------- STARTING DUMP ----------
[ 608.388333] dump_page: DUMP MARKER: 0x3
[ 608.388340] page:fffff7bad9e04fc0 count:2 mapcount:8192 mapping:ffffa0f08abdb358 index:0x0
[ 608.388347] flags: 0x17fffc00004007c(referenced|uptodate|dirty|lru|active|swapbacked)
[ 608.388353] raw: 017fffc00004007c fffff7bad9e049c8 fffff7bad9d09a08 ffffa0f08abdb358
[ 608.388358] raw: 0000000000000000 0000000000000000 0000000200001fff ffffa0f0a036e000
[ 608.388361] page dumped because: dump requested via ioctl
[ 608.388363] page->mem_cgroup:ffffa0f0a036e000
[ 608.388365] dump_page: ========== END OF DUMP ==========
[ 608.390616] dump_page: ---------- STARTING DUMP ----------
[ 608.390620] dump_page: DUMP MARKER: 0x4
[ 608.390624] page:fffff7bad9e04fc0 count:-510 mapcount:7680 mapping:ffffa0f08abdb358 index:0x1
[ 608.390628] flags: 0x17fffc000000004(referenced)
[ 608.390632] raw: 017fffc000000004 fffff7ba54000948 ffffa0f0b35e62f8 ffffa0f08abdb358
[ 608.390636] raw: 0000000000000001 0000000000000000 fffffe0200001dff 0000000000000000
[ 608.390639] page dumped because: dump requested via ioctl
[ 608.390641] dump_page: ========== END OF DUMP ==========
[...]
[ 608.409077] dump_page: ---------- STARTING DUMP ----------
[ 608.409079] dump_page: DUMP MARKER: 0x4
[ 608.409081] page:fffff7bad9e04fc0 count:-7678 mapcount:512 mapping:ffffa0f08abdb358 index:0x1
[ 608.409083] flags: 0x17fffc000000004(referenced)
[ 608.409085] raw: 017fffc000000004 fffff7ba54000948 ffffa0f0b35e62f8 ffffa0f08abdb358
[ 608.409086] raw: 0000000000000001 0000000000000000 ffffe202000001ff 0000000000000000
[ 608.409087] page dumped because: dump requested via ioctl
[ 608.409088] dump_page: ========== END OF DUMP ==========
[ 608.409988] dump_page: ---------- STARTING DUMP ----------
[ 608.409990] dump_page: DUMP MARKER: 0x5
[ 608.409992] page:fffff7bad9e04fc0 count:-8189 mapcount:1 mapping:ffffa0f08abdb358 index:0x1
[ 608.409994] flags: 0x17fffc000000004(referenced)
[ 608.409996] raw: 017fffc000000004 fffff7ba54000948 ffffa0f0b35e62f8 ffffa0f08abdb358
[ 608.409999] raw: 0000000000000001 0000000000000000 ffffe00300000000 0000000000000000
[ 608.410000] page dumped because: dump requested via ioctl
[ 608.410000] dump_page: ========== END OF DUMP ==========
As you can see, the reference count of the page (when interpreted as an unsigned
number) goes up to 2^32-1 and wraps around, then goes down again and wraps back.
When the refcount wraps back, the page AFAIU moves onto a freelist, and you can
see that e.g. its flags change at that point.
If you interact with the system a bit at this point, you'll soon run into
various kinds of kernel BUG()s.
My guess is that most people don't have machines with >=140GiB RAM at this
point, so luckily, issues like this are probably not a big problem for most
users yet.
As far as I can tell, there are a bunch of potential ways to deal with this
issue:
1. Make refcount/mapcount bigger; but as Matthew Wilcox points out in
<https://lore.kernel.org/lkml/20180208194235.GA3424@bombadil.infradead.org/>,
that would cost something like 2GiB of RAM on a machine with 1TiB RAM.
2. Dirty hack: Detect refcount/mapcount overflow and freeze them at a high
value, in order to deterministically leak references to that page.
Downside is that memory is still going to leak permanently.
This is what refcount_t does on X86 or when CONFIG_REFCOUNT_FULL is set.
3. Daniel Micay's suggestion: Dynamically switch from a small inline refcount to
an out-of-line refcount in some sort of lookup structure
(<https://lore.kernel.org/lkml/CA+DvKQKba0iU+tydbmGkAJsxCxazORDnuoe32sy-2nggyagUxQ@mail.gmail.com/>).
4. Ad-hoc fixes to keep the number of possible references down, see e.g.:
- https://lore.kernel.org/lkml/20180208213743.GC3424@bombadil.infradead.org/
- commit 92117d8443bc5afacc8d5ba82e541946310f106e ("bpf: fix refcnt overflow")
Number 1 is obviously correct, but probably unacceptable given its cost; number
4 is probably the next-easiest solution for any specific way to overflow some
reference counter, but as Daniel said, it smells of whack-a-mole.
That leaves numbers 2 and 3, I guess, unless someone has a better idea?
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/46745.zip
