Linux watch queue race lets unprivileged users panic the kernel

A race in the Linux kernel's watch-queue support can let an unprivileged process crash the machine with a null-pointer dereference and panic.

The problem is in how a notification pipe is sized after a watch may already be attached. The sizing path published the note buffer, bitmap, page count, and note count with ordinary stores and no lock, so the four values were not visible as a single unit. Depending on the compiler, the buffer pointer could land last. A concurrent notification could then see a non-zero count, pass its bounds check, and still read a null buffer, faulting in interrupt context. An unprivileged user can provoke this by attaching a watch on one of their own keys through a notification pipe, then racing the size ioctl against a keyctl permission change on another CPU.

Cen Zhang of Microsoft submitted a fix that takes the existing watch-queue lock around those publication stores, so a poster either sees a fully initialized pool or none of it. Zhang planned a follow-up that would replace the lock with release and acquire barriers on the note count. The bug has been present since general notification-queue support was added. It was reported by Dae R. Jeong and by Microsoft's Autonomous Code Security group. Greg Kroah-Hartman noted that public patches of this kind need not be copied to the kernel security list.