Subject: io_uring/eventfd: registered eventfd signals only once after the cd305ee3633a backport (6.18.y, 6.12.y, Ubuntu 26.04)

Subject: io_uring/eventfd: registered eventfd signals only once after the cd305ee3633a backport (6.18.y, 6.12.y, Ubuntu 26.04)

[dev]

While working on my own async runtime on io_uring, I found what looks like a defect in the stable backports. I first saw it on Ubuntu 26.04's kernel, and I can't find any existing report of it.

A registered io_uring eventfd stops signaling after its first deferred signal on kernels that carry the backport of cd305ee3633a ("io_uring: defer eventfd signaling when queued from a wakeup handler") but not 04fe9aeb4f3c ("io_uring/eventfd: reset deferred signal state").

What I see, on Ubuntu 26.04 7.0.0-1016-aws, x86_64 and arm64. Ubuntu's 7.0 kernel took the cd305ee3633a backport through the 6.18.49 stable update:
  
1. A ring with IORING_SETUP_SINGLE_ISSUER | IORING_SETUP_DEFER_TASKRUN | IORING_SETUP_TASKRUN_FLAG, and an eventfd registered with IORING_REGISTER_EVENTFD.
2. Two IORING_OP_RECV on a nonblocking TCP socket. Each gets -EAGAIN, arms poll, and later has data.
3. The first receive's task work signals the eventfd. For the second, tracing shows io_uring_task_add, but the eventfd never becomes readable, and poll() on it blocks.
4. io_uring_enter with IORING_ENTER_GETEVENTS then runs the work and posts the completion.

Debian 12's 6.1 kernel does not show this.

What I THINK is going on (I read the source, w/ help from Opus 5.5; please correct me if I'm wrong): after cd305ee3633a, task work queued from a poll wakeup signals through the deferred path, which sets IO_EVENTFD_OP_SIGNAL_BIT. Without 04fe9aeb4f3c, io_eventfd_do_signal() never clears that bit, so each later deferred signal is skipped.

Where it applies: cd305ee3633a is in 6.18.49 and 6.12.114. 04fe9aeb4f3c (Fixes: 60b6c075e8eb, in v7.1, no stable tag) is in neither branch, and I didn't find a copy in the stable queue. I read this in the source of the linux-6.18.y and linux-6.12.y heads, but I didn't run those kernels.

If this is correct, a backport of 04fe9aeb4f3c to 6.18.y and 6.12.y looks like the right fix; it keeps the CVE-2026-80920 fix in place. The 6.12.y code differs, so it may need a small change. I will obviously leave the fix to you, but I'm happy to test a candidate on the affected Ubuntu kernel.

Thanks,

Nathan - Founder, Lead Developer @ Rebased, Inc.

Re: Subject: io_uring/eventfd: registered eventfd signals only once after the cd305ee3633a backport (6.18.y, 6.12.y, Ubuntu 26.04)

[Greg KH]

On Fri, Nov 13, 2026 at 11:22:38PM +0000, dev@rebasedinc.com wrote:
> While working on my own async runtime on io_uring, I found what looks like a defect in the stable backports. I first saw it on Ubuntu 26.04's kernel, and I can't find any existing report of it.
> 
> A registered io_uring eventfd stops signaling after its first deferred signal on kernels that carry the backport of cd305ee3633a ("io_uring: defer eventfd signaling when queued from a wakeup handler") but not 04fe9aeb4f3c ("io_uring/eventfd: reset deferred signal state").
> 
> What I see, on Ubuntu 26.04 7.0.0-1016-aws, x86_64 and arm64. Ubuntu's 7.0 kernel took the cd305ee3633a backport through the 6.18.49 stable update:

Please test the real kernel.org 6.18.y release.  6.18.49 is very old.

If that still has a problem, please let us know and ideally send us a
backported patch.

thanks,

greg k-h

Re: io_uring/eventfd: registered eventfd signals only once after the cd305ee3633a backport (6.18.y, 6.12.y, Ubuntu 26.04)

[Sasha Levin]

On 2026-11-13, dev@rebasedinc.com wrote:
> If this is correct, a backport of 04fe9aeb4f3c to 6.18.y and 6.12.y looks like the right fix; it keeps the CVE-2026-80920 fix in place.

Queued for 6.18 and 6.12, thanks.

-- 
Thanks,
Sasha