Add kernelCTF CVE-2024-26824_mitigation by st424204 · Pull Request #256 · google/security-research

st424204 · 2025-09-24T05:37:23Z

No description provided.

update

update from upstream

koczkatamas

Please fix your submission to follow the style guide (it's a requirement!): https://google.github.io/security-research/kernelctf/style_guide

I left a few comments, but don't consider this as a comprehensive list of issues needs to be fixed.

koczkatamas · 2026-02-12T17:44:58Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+void do_spray()
+{
+    memset(payload, 0, 0x400);
+    *(size_t *)&payload[0] = ktext + 0x2db3720;


Comment what is 0x2db3720.

Resolved in the code. I've replaced 0x2db3720 with the CORE_PATTERN_OFFSET definition to make its intent clear.

koczkatamas · 2026-02-12T17:45:14Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+
+void do_spray()
+{
+    memset(payload, 0, 0x400);


Comment "payload == af_alg_sgl, sgl->sgt.sgl == core_pattern" (if that's correct).

Done. I've renamed payload to af_alg_sgl and updated the comments detailing how it points to core_pattern.

koczkatamas · 2026-02-12T17:45:56Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+
+#define STEXT 0xffffffff81000000
+
+unsigned long long fake_buf[43] = {


Include script which generates this buffer or describe how this was generated. Rename from fake_buf to something which clearly describes its purpose.

I've added detailed block comments to document the origin of this payload. Specifically, the array now directly contains the physical memory layout of a whole page (4KB) covering the core_pattern buffer string. This entire heap layout was dynamically dumped from GDB during exploit testing. Because the exploit relies on a data-oriented layout collision extracted via debugger dumps, an algorithmic generation script wasn't used.

koczkatamas · 2026-02-12T17:46:02Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+    0x0000000000001000,
+};
+
+unsigned long long fake_buf2[33] = {


Include script which generates this buffer or describe how this was generated. Rename from fake_buf2 to something which clearly describes its purpose.

(This comment originally applied to what is now merged into fake_buf). I've added extensive comments describing how fake_buf is literally a raw memory dump of an entire 4KB page structure

koczkatamas · 2026-02-12T17:46:24Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+#define ARRAY_LEN(x) (sizeof(x) / sizeof(x[0]))
+
+int tfmfd, opfd;
+char *victim_addr;


Done, unused variables have been removed.

koczkatamas · 2026-02-12T17:48:05Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+char payload[0x1000];
+int cfd[2];
+int sfd[0x200][2];
+pthread_t tid[0x100];


Use THREAD_NUM instead of 0x100

Done. Array allocations and loops now use THREAD_NUM.

koczkatamas · 2026-02-12T17:48:22Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+{
+    memset(payload, 0, 0x400);
+    *(size_t *)&payload[0] = ktext + 0x2db3720;
+    payload[560] = 0;


What field do you set here? Why?

remove unnecessary set

koczkatamas · 2026-02-12T17:48:48Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+        if (fake_buf2[i] > 0xffffffff81000000ULL)
+            fake_buf2[i] = fake_buf2[i] - 0xffffffff81000000ULL + ktext;
+
+    char* mem = SYSCHK(mmap(NULL, 0x30000000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0));


Explain why 0x30000000?

remove this unnecessary code

koczkatamas · 2026-02-12T17:49:15Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+        .rlim_max = 0xf000};
+    setrlimit(RLIMIT_NOFILE, &rlim);
+
+    int pfd[0x100][2];


Use PIPE_COUNT instead of 0x100.

koczkatamas · 2026-02-12T17:49:46Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+        char *anon = SYSCHK(mmap(NULL, 0x1000000, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0));
+        for (int i = 0; i < 0x1000000; i += 0x1000)
+        {
+            memcpy(anon + i + 0x3e0, fake_buf, 0x158);


Use defines for the offsets, so it's clear what is set.

koczkatamas · 2026-02-12T18:12:12Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+
+int tfmfd, opfd;
+char *victim_addr;
+char buf[0x5000];


Do not use global buf. Hard to understand what the code does.

Resolved. I removed the generic global buf variable entirely, and migrated thread synchronization logic to use local buffers like local_buf[0x1000] within the thread execution methods and sync_buf[1] inside main().

koczkatamas · 2026-02-12T18:12:32Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+        int n = 0x800;
+        setsockopt(sfd[i][1], SOL_SOCKET, SO_SNDBUF, (char *)&n, sizeof(n));
+        setsockopt(sfd[i][0], SOL_SOCKET, SO_RCVBUF, (char *)&n, sizeof(n));
+        write(sfd[i][1], buf, 0x1000);


What's the content of the buf at this point? Does it matter?

It does not matter! I've clarified this by changing the variable name to sync_buf and added a comment. It is just a 1-byte arbitrary token used to strictly block and synchronize unix socket thread states.

koczkatamas · 2026-02-12T18:14:00Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+        .msg_iovlen = 1,
+        .msg_iov = &iov,
+        .msg_control = buf,
+        .msg_controllen = 0x4cdf,


Why 0x4cdf?

I've updated the comment to be accurate. The size 0x4cdf is used to increase the sk_omem_alloc field until it is just below the optmem_max limit. This ensures that a subsequent sock_kmalloc call fails, which is the intended behavior to trigger the exploit's error path

koczkatamas · 2026-02-24T16:05:07Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+
+// Manually constructed fake pipe_buf_operations structure and stack pivot/ROP chain
+unsigned long long fake_ops_and_rop[43] = {
+    0xffffffff83db3480,


Comment on every element which fields are set (if they are structure fields) and which kernel symbols are used as values (or ROP chain gadgets).

its not relative to any rop, removed

koczkatamas · 2026-02-24T16:06:38Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+
+// Manually constructed fake pipe_buffer structure
+unsigned long long fake_pipe_buffer[33] = {
+    0xffffffff83257ccf,


Neither the size nor the content match the pipe_buffer structure:

struct pipe_buffer { struct page * page; /* 0 8 */ unsigned int offset; /* 8 4 */ unsigned int len; /* 12 4 */ const struct pipe_buf_operations * ops; /* 16 8 */ unsigned int flags; /* 24 4 */ long unsigned int private; /* 32 8 */ /* size: 40, cachelines: 1, members: 6 */ };

Please comment here what's here exactly.

its not relative to any fake_pipe_buffer, removed

koczkatamas · 2026-02-24T16:15:30Z

pocs/linux/kernelctf/CVE-2024-26824_mitigation/exploit/mitigation-v4-6.6/exploit.c

+        .msg_iovlen = 1,
+        .msg_iov = &iov,
+        .msg_control = msg_control_buf,
+        // Size 0x4cdf is chosen perfectly to corrupt the proper adjacent target cache object distance


Writeup says the goal of the call is to increase the sk_omem_alloc field, it says nothing about "corrupt the proper adjacent target cache object".

Also nothing about this mentioned in the "Step 3: Overwriting core_pattern and Root Shell Setup" section.

So what's this call doing?

The size 0x4cdf is used to increase the sk_omem_alloc field until it is just below the optmem_max limit. This ensures that a subsequent sock_kmalloc call fails, which is the intended behavior to trigger the exploit's error path

d4em0n and others added 12 commits July 14, 2025 16:15

Merge pull request #13 from google/master

4a4a0c6

update

Merge pull request #15 from google/master

e34dd30

update from upstream

[v8ctf] Update v8CTF challenges

84cce9a

Merge branch 'google:master' into master

f280f3b

[v8ctf] Update v8CTF challenges

c56561f

Merge branch 'google:master' into master

3a371fe

CVE-2024-26824_mitigation/

2c64e72

CVE-2024-26824_mitigation

589b817

fix

e840bd4

Update metadata.json

4f268aa

Update exploit.c

5aae20d

Update exploit.c

6cce0ca

st424204 force-pushed the CVE-2024-26824_mitigation branch from 513da39 to 6cce0ca Compare September 24, 2025 05:53

d4em0n added 3 commits September 24, 2025 14:27

remove useless msg_msg

7a838b8

Update exploit.c

61ae344

Update exploit.md

dd28092

koczkatamas added the kCTF: vuln OK The submission exploits the claims vulnerability (passed manual verification) label Sep 25, 2025

koczkatamas force-pushed the master branch from 19d0c10 to 24880bb Compare September 27, 2025 10:34

koczkatamas requested changes Feb 12, 2026

View reviewed changes

koczkatamas reviewed Feb 12, 2026

View reviewed changes

Improve_PR

ac10d15

koczkatamas requested changes Feb 24, 2026

View reviewed changes

st424204 added 2 commits February 25, 2026 17:28

Improve_PR

18c3671

done

49ba2d0

koczkatamas merged commit e0c4625 into google:master Feb 25, 2026
6 checks passed


		#define STEXT 0xffffffff81000000

		unsigned long long fake_buf[43] = {

Conversation

st424204 commented Sep 24, 2025

Uh oh!

koczkatamas left a comment

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!

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!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants