Add kernelCTF CVE-2025-38477_cos by n132 · Pull Request #268 · google/security-research

n132 · 2025-10-21T01:06:31Z

No description provided.

Clarify details about security vulnerabilities and mmap usage.

matrizzo · 2025-10-24T12:55:45Z

As discussed on Discord, please try to make the exploit reproduce on the CI.

n132 · 2025-10-24T17:16:39Z

As discussed on Discord, please try to make the exploit reproduce on the CI.

Thanks for the help. We'll try to make it more reliable on github action enviroment.

artmetla · 2026-02-24T21:03:15Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+refcount issue into a UAF to make it more robust.
+
+
+> Note on Original UAF Complexity: The original UAF primitive was also abandoned


Do I understand correctly that you decided to switch to another UaF primitive? If so, please rewrite the exploit.md to use correct one from the start. Starting from non-suitable or weak primitive obfuscates the logic and makes it harder to understand what is going on.

Yes, we are converting it to another primitive since the difficulty we mentioned, "Race Window" was small.

We considered starting with the final primitive, and it's gonna be hard to explain why we write exploitation in such a complex way. We thought it might give the readers more helpful information to show the procedure for why we need to change to the final primitive. We also think the steps to get the final primitive are valuable to exploit hard race conditions (we admit it is too long, and readers may lose patience, but it is how a complex exploitation was built).

I believe the race condition in case 3/4 is one of the core technical contributions of this exploitation and the most distinctive part of this work. While the heap cross-cache techniques are important, they are already well covered in other write-ups. In contrast, the race condition angle is what makes this analysis unique (valuable) and provides deeper insight into the underlying issue.

Please let me know how you think. If you insist, I would like to focus on the last primitive and how heap exploitation works.

artmetla · 2026-02-24T21:15:19Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+However, we got some good news!
+
+- Window1.width = $769.94$ cycles
+- Window2.width = $103.15$ cycles


I guess it's worth clearly specify that you're converting Case 3 into Case 2 with interrupt insertion (mentioned in ExpRace Section)

Sorry again for the confusion that the wrong statement brings.

We can't transform from one case to another with ExpRace. ExpRace is enlarging the window to make an impossible case2/3 race condition possible to happen.

It's fixed in the comment: #268 (comment)
and fix: eb0b7aa

artmetla · 2026-02-24T21:16:04Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+- Window2.width = $103.15$ cycles
+
+This larger target window size (Window2) is critical because it greatly improves
+the probability of a successful interrupt insertion (metioned in ExpRace


Suggested change

the probability of a successful interrupt insertion (metioned in ExpRace

the probability of a successful interrupt insertion (mentioned in ExpRace

Thanks for correcting the typo. Fixed in: f51d45d

artmetla · 2026-02-24T21:19:12Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+We began our investigation after our custom fuzzer triggered a null-dereference
+crash. By understanding the root cause, we realized the crash was a result of a
+Race Condition. After solving many challenges, we successfully transformed the
+initial bug into a Use-After-Free (UAF) vulnerability, ultimately perfoming


Suggested change

initial bug into a Use-After-Free (UAF) vulnerability, ultimately perfoming

initial bug into a Use-After-Free (UAF) vulnerability, ultimately performing

Thanks for correcting the typo. Fixed in: a653a87

artmetla · 2026-02-24T21:21:52Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+Therfore, we can only use method 2 to create a UAF primitive. Considering that
+we have to have one thread increase the refcount and another to decrease the
+refcount, `qfq_change_agg` must be used to increase the refcount. Thus, we have
+Thread 1 calling `qfq_chaneg_agg` and Thread 2 calling `qfq_delete_class`. There


Suggested change

Thread 1 calling `qfq_chaneg_agg` and Thread 2 calling `qfq_delete_class`. There

Thread 1 calling `qfq_change_agg` and Thread 2 calling `qfq_delete_class`. There

Thanks for correcting the typo. Fixed in: 3c29d4c

artmetla · 2026-02-24T21:28:16Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+
+The net effect is that the true reference count has gone from $N$ to $N+1$ (by
+Thread 1) and then back to $N-1$ (by Thread 2's overwrite), while the real agg
+referrence counter is $N$. This achieves the target miscount: `Refcount ($N$) >


Suggested change

referrence counter is $N$. This achieves the target miscount: `Refcount ($N$) >

reference counter is $N$. This achieves the target miscount: `Refcount ($N$) >

Thanks for correcting the typo. Fixed in: 8c8e15c

artmetla · 2026-02-24T21:59:43Z

pocs/linux/kernelctf/CVE-2025-38477_cos/docs/exploit.md

+- What to write (solved by `NPerm`)
+
+## UAF Unlink Attack Targeting Linked Lists: LL_ATK
+


The exploit code does a lot of "Heap Feng Shui" like

XDP UMEM Spraying

Partial Slab Filling: The code uses partial_slab_obj loops to plug holes in the kmalloc-128 cache before triggering the vulnerability.

Warm-up Phases: The warm() function sends specific netlink messages to stabilize the heap state.

The write-up should include a section detailing the slab layout strategy. How did you ensure that the freed qfq_aggregate object was cleanly refilled with your payload so that hlist_del_init operated on attacker-controlled pointers?

I didn't use XDP for complex spraying. It's just for kmalloc-256 (It's cleaner than key, but we can use any other primitive).

Yes, I did use 0x8 (>=0x7) slabs to fill cpu partial

Warm-up is not for the heap but for caching. QEMU VM's first syscall is super slow and not stable, while winning the race requires it to be more stable/predictable. So we warm up.

I see it. I didn't include them since the heap layout is actually not complex (0x80*0x100 before + after, using CPU partial + huge page eviction skills).

I added some comments in exploit.c in: 56d5aa3
I'll add the explaination in the md file, too.

The heap related explaination is added in: 84bdead

artmetla · 2026-02-24T22:31:04Z

@n132 Thanks for the great and quick fixes. Please, modify/answer the rest of the question and I'll be ready to merge the PR.

n132 · 2026-02-24T22:32:54Z

@n132 Thanks for the great and quick fixes. Please, modify/answer the rest of the question and I'll be ready to merge the PR.

Thanks so much for the detailed review. I'll work on these comments and inform you when they're done.

n132 · 2026-02-25T20:41:11Z

Hi @artmetla, I resolved all the existing comments. Please let me know if these updates are still not clear. Thanks for your review again. Feel free to ask more questions. The exploit.c seems broken, but we can fix it later when there are no more style/format required changes on exploit.c

n132 and others added 18 commits October 20, 2025 17:50

Add kernelCTF CVE-2025-38477_cos

bd34894

Add deps for CVE-2025-38477: libx

a4829bf

CVE-2025-38477: Update metadata

6e800d4

CVE-2025-38477: Update metadata

4b31a65

Add CVE-2025-38477_cos: Solve the dep issue

b965621

Add CVE-2025-38477_cos: debug mode

e5ac2ae

resubmit: retry the checks

5fac98f

Update exploit.md

40a22a8

CI: Fix the timeout issue

57d112a

Merge branch 'master' of https://github.com/n132/security-research

66ac3e2

CI: Fix the timeout issue

7be891b

CI: Fix the timeout issue

0fcb6a2

CI: Fix the timeout issue

bbffd62

CI: Retest

36c3d66

More trial

4ec38ce

Update exploit.md

2a320ac

Update exploit.md with vulnerability details

f479e67

Clarify details about security vulnerabilities and mmap usage.

CI: Retest

30e37be

winmin force-pushed the master branch from d2d844b to 0fcb6a2 Compare October 27, 2025 06:27

winmin and others added 9 commits October 28, 2025 17:56

CI Reset & document format

97468cf

Merge branch 'master' of https://github.com/n132/security-research

467777b

reset

7e35086

Update with correct kaslr leak

dfc301f

Update with correct kaslr leak

5853450

Make it debugable

5431878

[v8ctf] Update v8CTF challenges

abe30f0

fix: kaslr leaking

d17719b

Merge branch 'google:master' into master

a692b05

artmetla reviewed Feb 24, 2026

View reviewed changes

chore: more comments for exploitation

56d5aa3

artmetla reviewed Feb 24, 2026

View reviewed changes

n132 added 3 commits February 24, 2026 14:28

Exploitation for Nperm

6d694c9

More comment for used objects

1296989

Writing: update

1ade73c

artmetla reviewed Feb 24, 2026

View reviewed changes

n132 added 16 commits February 24, 2026 15:44

Chore: writing

855379e

Fix a wrong statement

9a69f4b

Doc: more explanation

39466d1

Doc: Tip for readers

ef8d37a

Fix: typo

b3c8385

DoC: Details about nonfull_aggs

bbe00c3

Fix: typo

77b7ff2

Revert a change

5040c0f

Doc: Clarify

812a635

More explain

eb0b7aa

Doc: Typo

f51d45d

Doc: Typo

a653a87

Doc: Typo

3c29d4c

Doc: Typo

8c8e15c

Doc: Typo fixes

76b6b78

Doc: Heap related

84bdead

		refcount issue into a UAF to make it more robust.


		> Note on Original UAF Complexity: The original UAF primitive was also abandoned

	the probability of a successful interrupt insertion (metioned in ExpRace
	the probability of a successful interrupt insertion (mentioned in ExpRace

	initial bug into a Use-After-Free (UAF) vulnerability, ultimately perfoming
	initial bug into a Use-After-Free (UAF) vulnerability, ultimately performing

	Thread 1 calling `qfq_chaneg_agg` and Thread 2 calling `qfq_delete_class`. There
	Thread 1 calling `qfq_change_agg` and Thread 2 calling `qfq_delete_class`. There

	referrence counter is $N$. This achieves the target miscount: `Refcount ($N$) >
	reference counter is $N$. This achieves the target miscount: `Refcount ($N$) >

		- What to write (solved by `NPerm`)

		## UAF Unlink Attack Targeting Linked Lists: LL_ATK

Conversation

n132 commented Oct 21, 2025

Uh oh!

matrizzo commented Oct 24, 2025

Uh oh!

n132 commented Oct 24, 2025

Uh oh!

artmetla Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

artmetla commented Feb 24, 2026

Uh oh!

n132 commented Feb 24, 2026

Uh oh!

n132 commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

artmetla Feb 24, 2026 •

edited

Loading