[BUG] watch_queue: RCU/info_id overlap leaks kernel stack

[BUG] watch_queue: RCU/info_id overlap leaks kernel stack

[Zhiyu Zhang]

Hello Linux Kernel Developers and Maintainers,

We found a race in watch_queue that lets an unprivileged process over-read the
kernel stack of the task posting a key notification. On x86-64 the disclosure
contains that task's stack canary, kernel-stack and task_struct pointers, and
two return addresses that reveal the KASLR slide.

The bug was introduced by c73be61cede5882f9605a852414db559c0ebedfd
("pipe: Add general notification queue support") and is present in current
mainline d135ab453a7400a34930bdda1ef4bdc8acfac80e. We reproduced it there as
an ordinary user. CONFIG_WATCH_QUEUE and CONFIG_KEY_NOTIFICATIONS are
required.

Root cause:

struct watch overlays u32 info_id with struct rcu_head. A notification poster
reads info_id under rcu_read_lock(), but a concurrent final put can enqueue the
watch with call_rcu(). Enqueueing the callback writes rcu_head before the
grace period ends, replacing info_id while the object remains visible to the
reader.

__post_watch_notification() then merges the corrupted value into the
notification info word without masking it. Pointer bits can enter
WATCH_INFO_LENGTH, causing post_one_notification() to copy beyond the 16-byte
notification record from the posting task's live stack into the
attacker-readable pipe.

This disclosure is independently security-relevant. It is also the canary
and KASLR bypass for the TCP stack overwrite reported in:

https://lore.kernel.org/netdev/CALf2hKvp0NPVLwr=a3+jUHtPohxbra8gox+aYAfWathJnn-J+Q@mail.gmail.com/T/#u

We demonstrated uid 65534 to root by composing the two issues in the same
unprivileged thread.

Reproduction and fix:

We have a short source reproducer, exact config and QEMU results. In
accordance with the kernel policy, we are not posting the reproducer publicly.
We can provide it privately if a maintainer requests it. On the vulnerable
baseline it normally reports the canary, stack/task pointers and two agreeing
KASLR anchors within a few seconds.

Our tested fix gives info_id storage separate from rcu_head and masks it with
WATCH_INFO_ID before merging it into a notification. On x86-64, placing
info_id after the kref consumes existing tail padding and does not change the
size of struct watch. We will post the mergeable patch separately and link
that thread here.

AI-agent tooling assisted in identifying and analyzing the issue, developing
the reproducer, and preparing the initial fix. The reporters reviewed the
affected paths and reproduced the issue and the fixed result in QEMU.

Reported-by: Tong Liu <lyutoon@gmail.com>
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Zhiyu Zhang <zhiyuzhang999@gmail.com>

Best regards,
Zhiyu Zhang

Re: [BUG] watch_queue: RCU/info_id overlap leaks kernel stack

[Jarkko Sakkinen]

On Wed, Oct 28, 2026 at 11:41:35PM +0800, Zhiyu Zhang wrote:
> We have a short source reproducer, exact config and QEMU results. In
> accordance with the kernel policy, we are not posting the reproducer publicly.
> We can provide it privately if a maintainer requests it. On the vulnerable
> baseline it normally reports the canary, stack/task pointers and two agreeing
> KASLR anchors within a few seconds.

This is public nobody cares. Likely I could make the reproducec with a
couple of prompts. 

What if you instead spent some time with your "short reproducer" and figure
out how to make equal reproducer with bash and keyctl? It's a good
habbit and helps to check the relevance because you have to think things
through.

This announcement is just total waste of time and energy anyhow.

Br, Jarkko

Re: [BUG] watch_queue: RCU/info_id overlap leaks kernel stack

[Zhiyu Zhang]

Hi Jarkko,

Sorry for disturbing, and thank you for the concrete suggestion.
We have now reduced the watch_queue issue to a shell + keyctl reproducer
using watch_session, watch_add and timeout.

We will send the reproducers (including the complete exp for lpe) to you
and the relevant maintainers privately. I understand your point that a
similar reproducer can likely be recreated with a few LLM prompts.
Nevertheless, Documentation/process/security-bugs.rst says not to
publish a reproducer for an AI-assisted finding, so we are keeping it off-list.
The same guidance says that AI-assisted findings must be treated as public,
which is why the report was posted publicly.

We have also prepared the fix and verified locally that it prevents the
issue. We sent the report first so that the patch commit can carry the
stable lore URL in its Closes: trailer. We will post the patch for review asap.

Best,
Zhiyu

Jarkko Sakkinen <jarkko@kernel.org> 于2026年10月28日周三 23:56写道：
>
> On Wed, Oct 28, 2026 at 11:41:35PM +0800, Zhiyu Zhang wrote:
> > We have a short source reproducer, exact config and QEMU results. In
> > accordance with the kernel policy, we are not posting the reproducer publicly.
> > We can provide it privately if a maintainer requests it. On the vulnerable
> > baseline it normally reports the canary, stack/task pointers and two agreeing
> > KASLR anchors within a few seconds.
>
> This is public nobody cares. Likely I could make the reproducec with a
> couple of prompts.
>
> What if you instead spent some time with your "short reproducer" and figure
> out how to make equal reproducer with bash and keyctl? It's a good
> habbit and helps to check the relevance because you have to think things
> through.
>
> This announcement is just total waste of time and energy anyhow.
>
> Br, Jarkko
>
>