Most of what we ask a model to do with code is generate it. This time we pointed tAI 4.2 at an existing, already-shipping codebase and asked it to review, not write, and it came back with a genuine, exploitable kernel bug, scored and published the same way any real CVE would be.
What it found
In keyboard_poll() of keyboard.c, an unconditional sti at the end of the function re-enabled maskable interrupts regardless of the caller's context. That function is reachable from keyboard_getchar(), which a ring3 userspace program can block on via SYS_READ, entered through the int $0x80 gate (which clears the interrupt flag for the duration of the syscall by design).
The unconditional sti silently re-enabled interrupts in the middle of that syscall handler, letting the 100Hz PIT timer preempt mid-handler: a nested hardware interrupt firing while the CPU was already inside another interrupt's own trap-gate handler. That corrupted ring3 register and stack state on return to userspace, producing a reliable General Protection Fault the moment a program performed its first blocking keyboard read.
Any ring3 program using tos_read() / tos_readline() on stdin could trigger this deterministically: full denial of service, via the kernel's own unrecoverable panic handler.
References
- github.com/Artfical/tOS/commit/2670e13
- github.com/Artfical/tOS/commit/6267b64
- github.com/Artfical/tOS/blob/main/kernel/drivers/input/keyboard.c
- db.artfical.com/asi/ASI-2026-0013
The fix was small: scope the sti to only run when interrupts were actually enabled on entry. But finding it required actually tracing interrupt-flag state across a syscall boundary, not just pattern-matching on suspicious code. That's the kind of review we built tAI 4.2 for.