leave

i do linux kernel and x86 stuff for fun

CTF player at @TheRomanXpl0it

[domas @xoreaxeaxeax]

New exploit: “xor dword [0xf80c2094], 1<<22”

Unlocks CPU microcode, the platform security processor, system management mode, and every internal processor register, all at once, on 100 million AMD CPUs. As far as I can tell can’t be fixed.

https://t.co/sgAfneFSsf

[domas @xoreaxeaxeax]

New primitive against x86's shadiest mode:

SMM has a critical barrier forcing cores to sync before running privileged code. Conveniently, the barrier has a timeout, which breaks for the funniest possible reason.

https://t.co/VVRFblc7u9

Pointlessly flashy GUI for effect.

[Qyn @qynln]

For this (maybe last) year of SekaiCTF I made a fullchain challenge, chaining together an 0-day in ladybird/libjs, an 0-day qemu TCG LPE and a n-day qemu escape:

https://t.co/w8KbB5EUMg

We also re-released another challenge with a running bounty until next week!

[kqx @kqx_io]

Great challenge from SekaiCTF by Qyn, the writeup is absolutely a must-read!

Happy to see that people find our fw_cfg technique useful

[0xor0ne @0xor0ne]

Analysis of a Chrome V8 Maglev Phi untagging vulnerability (CVE-2026-4447)

https://t.co/rzPSbkYlcP

Credits @kqx_io

#infosec

[V4bel @v4bel]

🚨 Introducing "ITScape" (CVE-2026-46316)

A Guest-to-Host Escape in KVM/arm64. Guest-side actions alone exploit a use-after-free to run root-privileged code in the host kernel.

Unlike the commonly published QEMU escapes, the bug lives in in-kernel KVM, not QEMU. On a successful exploit, commands run with host kernel privilege rather than the privilege of a user process, threatening the guest-host isolation of multi-tenant arm64 public clouds.

To the best of public knowledge, the first Guest-to-Host Escape Exploit targeting in-kernel KVM/arm64.

Details: https://t.co/CtZOQEzIdg

[kqx @kqx_io]

Pwning V8CTF with a 0day in Chrome thanks to Phi untagging.

Read here: https://t.co/dFDPRFnGLM

[Jenny Qu @GuanniQu]

found a verifier/interpreter mismatch in the Linux BPF subsystem (CVE-2026-31525, CVSS 7.8). arbitrary kernel read/write; become root, escape containers, disable SELinux, read TLS keys out of other processes' memory.
anyway, it starts with the math bars, the absolute value.
computers store negative numbers in two's complement. the smallest 32-bit signed integer is -2,147,483,648, and the largest positive is +2,147,483,647. there is no +2,147,483,648, since it simply does not fit. so when you call abs(-2,147,483,648), the C specification thinks about it for a moment, says "undefined," and leaves the room. on x86 and arm64, what you actually get back is -2,147,483,648. you asked for the absolute value of a negative number, you got back the same negative number. thank you computer :D
the BPF interpreter implements signed 32-bit division (BPF_ALU | BPF_DIV/MOD, off == 1, added in ec0e2da95f72) by decomposing it into unsigned division: take abs() of both operands, divide via do_div(), reapply the sign. the handler in ___bpf_prog_run (kernel/bpf/core.c):
AX = abs((s32)DST);
AX = do_div(AX, abs((s32)SRC));
and look, the kernel even documents this. include/linux/math.h: "the return value is undefined when the input is the minimum value of the type." when DST = 0x80000000 (S32_MIN), abs() tries to negate it. -(-2,147,483,648) overflows s32, the C spec calls it undefined behavior, and the CPU hands back 0x80000000 unchanged. still negative. abs() had one job.
this s32 then gets assigned into AX, a u64 BPF register. s32 → u64 sign-extends: 0x80000000 becomes 0xFFFFFFFF80000000. that's 18,446,744,071,562,067,968. you wanted 2,147,483,648, you got 18.4 quintillion; a rounding error of about 18.4 quintillion. do_div() is a 64-by-32-bit unsigned division macro and it operates on this full u64 numerator. the quotient is off by a factor of 2³². the smod path has the same problem since do_div() modifies the dividend in place and returns the remainder, both wrong. 8 call sites across sdiv32/smod32 src/imm handlers, all quietly producing nonsense whenever S32_MIN shows up.
the BPF verifier is the safety system that statically analyzes every BPF program before allowing it to run. it exists specifically to guarantee that nothing bad can happen. scalar32_min_max_sdiv() in kernel/bpf/verifier.c tracks value ranges through abstract interpretation. it handles signed division correctly, including S32_MIN. computes tight, mathematically correct bounds. the interpreter, as we've established, computes whatever it feels like. so the verifier thinks register R0 is in range X. the interpreter puts value Y in R0. the safety system and the execution engine disagree about what a program does. in BPF security research, this is where you set down your coffee.
concretely: load S32_MIN into R1, load 2 into R2, execute SDIV32 R1 R2. verifier determines R1 ∈ [-1,073,741,824, -1,073,741,824]. interpreter computes do_div(0xFFFFFFFF80000000, 2) = 0x7FFFFFFFC0000000, reapplies the sign, produces a completely unrelated value. use R1 as an index into a BPF map. verifier approves the access, bounds check passes against its calculated range. interpreter uses the actual value. out-of-bounds read/write on a kernel data structure. on every Linux machine running the BPF interpreter.
the root cause of all of this: the absolute value function doesn't handle one number. one specific number, out of 4.2 billion possible inputs, and it's the one that gives you kernel read/write. the fix is:
c
static u32 abs_s32(s32 x)
{
return x >= 0 ? (u32)x : -(u32)x;
}
cast to u32 before negating. -(u32)0x80000000 = 0x80000000 unsigned. correct absolute value, no overflow, no undefined behavior. the kind of function you'd assume already exists somewhere in 30 million lines of kernel code. it did not. I got to write it. :D
I reported this, wrote the patch, got it through 5 revisions of review. acked by Yonghong Song and Mykyta Yatsenko. now patched in stable 6.6, 6.12, 6.18, 6.19. if you haven't updated your kernel: maybe do that.

[kqx @kqx_io]

DEF CON patched our QEMU nday, what about a 0day?
https://t.co/AZcNzAQY9P

[kqx @kqx_io]

we wonder how this post got engagement boost during DEF CON Quals
https://t.co/OYElPVDjOp

[V12 @v12sec]

today we are releasing a qemu escape

[Salvatore Abello @salvatoreabello]

💿Crafting shared object/image polyglots by abusing a forgotten image format: https://t.co/1u36viN4FE

[starlabs @starlabs_sg]

We're likely 1st to publicly exploit crypto: af_alg as a new attack surface in kernelCTF. Our members @n0psledbyte & @st424204 started poking it in Sep 2025, finding a 0-day container escape unnoticed since 2011. @AnthropicAI @OpenAI: interested in collaborations? We are all ears

[kqx @kqx_io]

We just posted six new writeups for TRX CTF Quals at https://t.co/xK6jr0XAHs

Check them out!

[TRX @TheRomanXpl0it]

"hey claude plz solve all challenges https://t.co/CxLn0CrQhW"

TRX CTF 2026 is coming back this weekend with many cool challenges! Register now at: https://t.co/XYP0EMRlja

Top 8 teams will qualify for on-site finals in Italy this autumn🐴

[kqx @kqx_io]

less than three days left until the start of TRX CTF!
get ready for:
- two kernel pwn challenges
- browser shenanigans
- a *real* x86 challenge
- reversing a kernel module
make sure to register and fight for a spot in the finals in Italy!
https://t.co/knB1TkmHcf

[Nebula Security @nebusecurity]

In March, our pipeline discovered a critical vulnerability in the Linux kernel’s netfilter subsystem. We exploited this vulnerability and earned $10,050 in kCTF. In this post, we walk through the technical details of the vulnerability and the exploit. Link post below

[kqx @kqx_io]

"Claude find a 0day, make no mistakes"

CVE-2026-4447

https://t.co/4jISoO01go

[kqx @kqx_io]

played DiceCTF quals and managed to blood the kernel pwn challenge and won the $150 bounty!

check out the writeup: https://t.co/Jnw80IyrJh

[OtterSec @osec_io]

We recently achieved guest-to-host escape by exploiting a QEMU 0day.

We’ll share details on a new technique leveraging the latest glibc allocator behavior and what we believe is a novel QEMU-specific heap spray/RIP-control primitive.

Writeup coming next week.