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.