Add kernelCTF CVE-2026-43499_lts_cos

[nebusecurity]

No description provided.

[nebusecurity]

Hi, we’ve achieved a 10/10 success rate in reproducing the exploit on LTS-6.12.80.

However the vulnerability verification seems to have failed due to CI issues beyond our control.

Please let us know if there is anything else we need to do. Thanks!

[koczkatamas]

Hey!

It seems that the CI issue was only a one-off error, I've ran the vuln-verify process again and now it finished, but it could not cleanly verify the submission.

The run: https://github.com/google/security-research/actions/runs/28435044372/job/84258832987
The logs: https://github.com/google/security-research/actions/runs/28435044372/artifacts/7978337325

I can see from the logs that the patched kernel version is not affected (exploit exits cleanly), but on the non-patched version the kernel got into a soft lockup:

[   28.678942] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [exp:130]
[   28.678957] Modules linked in:
[   28.678962] CPU: 0 UID: 1000 PID: 130 Comm: exp Not tainted 7.0.0+ #1 PREEMPTLAZY 
[   28.678966] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   28.678968] RIP: 0010:rt_mutex_adjust_prio_chain+0x188/0x1fe0
[   28.678979] Code: 7e 18 83 f8 63 7f 08 39 f8 0f 84 8b 03 00 00 4c 89 ff e8 db 7a 00 00 85 c0 0f 85 0c 01 00 00 48 8b 3c 24 e8 5a 89 00 00 f3 90 <48> 8b 3c 24 e8 ef 87 00 00 48 8b 44 24 18 80 38 00 0f 85 0f 15 00
[   28.678981] RSP: 0018:ff11000106877c78 EFLAGS: 00000202
[   28.678984] RAX: 0000000000000001 RBX: ff11000106807c20 RCX: ffffffff85bcc4f1
[   28.678986] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ff1100010685a20c
[   28.678988] RBP: dffffc0000000000 R08: 0000000000000000 R09: fffffbfff0b958cc
[   28.678989] R10: ffffffff85cac663 R11: ff11000151a41af8 R12: ff1100010685992c
[   28.678991] R13: ff110001068598c0 R14: ff11000106807c08 R15: ffffffff85cac660
[   28.678993] FS:  00007a64d9d01640(0000) GS:ff110001c7b36000(0000) knlGS:0000000000000000
[   28.678995] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   28.678996] CR2: 0000000023ba9a98 CR3: 0000000106759004 CR4: 0000000000373ef0
[   28.679006] Call Trace:
[   28.679012]  <TASK>
[   28.679016]  __sched_setscheduler+0x656/0x2b00
[   28.679022]  ? __pfx___sched_setscheduler+0x10/0x10
[   28.679024]  ? __check_object_size+0x4b/0x650
[   28.679030]  __x64_sys_sched_setattr+0x15e/0x4c0
[   28.679032]  ? __pfx___x64_sys_sched_setattr+0x10/0x10
[   28.679035]  ? ret_from_fork+0x1c7/0x650
[   28.679040]  ? switch_fpu_return+0xf4/0x230
[   28.679042]  do_syscall_64+0xdc/0x680
[   28.679047]  ? __switch_to_asm+0x33/0x70
[   28.679052]  entry_SYSCALL_64_after_hwframe+0x76/0x7e

I see from the stack trace (esp. rt_mutex_adjust_prio_chain) that the exploit triggers the vulnerability, so I consider this manually verified, but can you help me understand an aspect better: this build runs with KASAN enabled, do you know why the dangling pointer here does not trigger a KASAN violation?

[koczkatamas]

Oh and we need an email confirmation before sending the reward, please check your email address(es) and your Bughunters' submission.

[nebusecurity]

Hi KT, we should have confirmed the verification email.

This build runs with KASAN enabled. Do you know why the dangling pointer here does not trigger a KASAN violation?

We believe this is because the UAF (dangling pointer) occurs on the stack, so the current KASAN implementation, or other detection mechanisms such as PAC or MTE, cannot detect this stack UAF.
That is also why we still keep the spray-reclaim logic in the vuln-verify path to try to trigger a non-canonical address dereference.

KASAN may have been able to detect this before torvalds/linux@7771bdb