elisaproject

Swiss Cheese Kernel Heap

This leaves behind memory pages that are:

• partially used
• not reclaimable
• and therefore fragmented

This creates a layout where:

kernel allocations are spread across many partially filled pages

Which is exactly the condition needed to increase the chance of:

kernel page → next → user page adjacency

Think of memory like a block of cheese:

• temporary allocations = drilling holes
• persistent objects = small solid parts left behind

After removing the temporary allocations:

you don’t get a clean empty block you get a holey structure the kernel cannot easily compact

The Key Result

After:

• fixing classification
• aligning granularity
• adding controlled fragmentation

We can say:

Kernel and user pages can be physically adjacent. Not always. Not everywhere. But definitely possible.

And importantly: this can happen naturally on a real system while in a VM it may require forcing conditions

Looking Closer (a.k.a. “What Exactly Is Sitting at the Edge?”)

At this point, we knew that: kernel pages and user pages can be physically adjacent. Which is already interesting.

But adjacency alone does not tell us how easy it is for trouble to cross the border.

If the last object in the kernel page ends hundreds of bytes before the page boundary, then an overflow would need to be fairly enthusiastic.

If instead the object ends exactly at the page boundary…

then even a tiny mistake can immediately step into the next page.

So the obvious next question was: “What is actually sitting at the very end of the slab page?”

Teaching the Tool Some Slab Archaeology

The original direct_map_view PoC was good at classifying pages.

The updated version became slightly more nosy.

Given a user page, it now:

• looks at the preceding PFN,
• checks whether that PFN is slab-backed,
• scans the page,
• and identifies the kernel object closest to the end of the page.

Using kmem_dump_obj(), the probe can determine which slab cache owns the object and where the object begins.

In other words: we stopped looking only at pages and started looking at what is actually living inside them.

A Typical Result

[   66.010479] pfn_slab_probe: input_pfn=1078469 checked_pfn=1078468 flags=0xbfffe0000000200
[   66.010862] pfn_slab_probe: checked PFN 1078468 is slab-backed, scanning [ffff0000c74c4000 - ffff0000c74c5000)
[   66.011652] slab kmalloc-512 start ffff0000c74c4e00 pointer offset 504 size 512
[   66.013007] pfn_slab_probe: nearest candidate object at ffff0000c74c4ff8, offset 0xff8 into PFN 1078468

The probe did not find an object starting at 0xff8.

It found itself standing 8 bytes before the edge of the page, inside a kmalloc-512 object, at offset 504 from the beginning of that object.

So the math is:

0xff8 - 504 = 0xe00

The object starts at 0xe00 and, being 512 bytes long, ends at 0x1000.

Exactly at the page boundary. Which is the memory-management equivalent of parking with the bumper touching the wall.

Turning Logs into Pictures

Because hexadecimal offsets are excellent at convincing computers but less effective with humans, a small script was added to convert the logs into SVG diagrams.

The result is a picture showing:

• the slab page,
• the last kernel object,
• the page boundary,
• and the user page immediately after it.

Sometimes, a drawing is worth several hundred printk()s.

From “Interesting Layout” to “Well… That Escalated Quickly”

At this point, we had demonstrated that:

• a kernel object can sit at the end of a page,
• the next physical page can belongs to a user process.

The next question was unavoidable: “What happens if the kernel writes past that boundary?”

Fortunately for science, and slightly less fortunately for the victim process, we now have a PoC for that too.

The Victim (a.k.a. “The Simplest Program We Could Get Away With”)

The userspace target is a tiny assembly program, available for both:

• AArch64 version
• x86_64 version

Its behavior is intentionally boring:

1. print the address of a string,
2. wait,
3. print the string,
4. exit.

That is all. No threads. No libraries. No excuses. If something changes, we know exactly who to blame.

Was it that simple?

The PoC script: poc.sh

Coordinates with the kernel module: umem_poke.c

The script does not do magic address translation in bash.

Which is probably good news for everyone. It only coordinates the experiment: it starts the victim, gets the address printed by the process, and passes that VMA address to the module.

The module is the one doing the kernel-side work. It uses GUP to resolve the userspace address to the underlying page, computes the linear mapping address destination byte, and then performs the write.

After all that machinery, the corruption itself is still disappointingly simple:

*dst_target = act.value;

That is it.

• No ptrace().
• No copy_to_user().
• No access_ok().
• No “Dear Kernel, may I please touch userspace?”

Just a normal assignment. From the kernel’s point of view, this is simply a write to a valid pointer.

Which leads to a slightly uncomfortable realization: once a userspace page is reached through the linear mapping, it stops being special. It is just memory. And the kernel is very good at writing to memory.

“But Surely Read-Only Memory Is Safe?”

A reasonable objection is: “Fine, but this probably works only on writable pages.” That would be reassuring… Would it really?

Even then, the wall would still have a door. Unfortunately, reality is even less reassuring.

The experiment works even when the target string is moved from .bss to .rodata.

In other words, the process sees the page as read-only. The process itself cannot modify the string.

And yet, after the userspace address has been translated to its corresponding location in the linear mapping, changing the supposedly immutable data still requires nothing more sophisticated than:

*dst_target = act.value;

• No page permissions are changed.
• No special write mechanism is invoked.
• No dedicated “modify userspace memory” API is used.

Just a normal store through a valid kernel pointer.

So the surprising part is not that the kernel, in principle, has enough privilege to modify the page. The surprising part is that once the page is reached through the linear mapping, the actual modification is indistinguishable from writing to any other ordinary kernel address.

Same physical page. Different virtual permissions. Same single dereference.

The Grand Finale

Before the write, the program prints one string.

After the write, it prints a different one.

buildroot login: root
# /usr/umem_poke/poc.sh 
running without corruption
message address: 0x0000000000400168
<TOKEN>

running again with corruption
[   27.675393] umem_poke: loading out-of-tree module taints kernel.
message address: 0x0000000000400168
[   28.751270] umem_poke: req: poke memory for pid=107 mem[400168]=1074707572726f63
[   28.752020] umem_poke: act: poke memory for pid=107 mem[400168]=1074707572726f63
corrupt
# 

The process does not crash. The kernel does not panic. No alarms ring. No dramatic music starts.

The application simply continues running with modified data. Which, from a functional safety perspective, is often the most interesting outcome.

Not: “The system exploded.”

But: “The system kept working… incorrectly.”

From Layout Curiosity to Concrete Effect

At this point, the full chain becomes visible:

+---------------------------+
|   shared physical memory  |
+---------------------------+
              |
             \ /
              V
+---------------------------+
|     possible adjacency    |
+---------------------------+
              |
             \ /
              V
+---------------------------+
| kernel object at page end |
+---------------------------+
              |
             \ /
              V
+---------------------------+
|   kernel write defect     |
+---------------------------+
              |
             \ /
              V
+---------------------------+
|   ordinary pointer store  |
+---------------------------+
              |
             \ /
              V
+---------------------------+
| userspace data corruption |
+---------------------------+
              |
             \ /
              V
+---------------------------+
|  incorrect but apparently |
|       normal behavior     |
+---------------------------+

So the original question: “Can kernel and user pages be physically adjacent?”

Now has a more complete answer: Yes. And if a kernel write goes in the wrong direction, the next page may belong to a perfectly innocent process. That process may continue running as if nothing happened, except for the small detail that its data is no longer what it thinks it is.

Why This Matters

From a safety perspective, the concern is not: user → kernel corruption (blocked by MMU)

The concern is:

kernel → anything else

Because in the linear mapping:

• everything shares the same physical space
• adjacency is not controlled
• allocators optimize for performance, not isolation

So when something goes wrong: the target is simply “the next page”

And what that page is… depends on the moment.

Bigger Picture

This PoC is not proving a vulnerability.

It is proving something more subtle: Linux enforces virtual access separation, but does not guarantee physical separation between kernel and userspace allocations.

And in safety: lack of guarantees is already a problem.

Final Thought

The tool didn’t find a bug and this article does not imply Linux is unsafe. It found something more annoying: an assumption that is not always true.

Meaning that physical separation is not an inherent property of the Linux memory manager and must be established through additional architectural controls if required by a safety case.