Re: [BUG] fs/aio: io_setup integer wrap can exhaust global aio quota

[Cheng Yongkang <teel4res@gmail.com>]

Hi Ben,

Thanks for the reply. I agree with the security triage: reaching this path
requires root to raise fs.aio-max-nr to an unreasonable value, and I am not
claiming a memory-safety issue, privilege-boundary bypass, or UAF. The impact
is limited to global AIO quota accounting under that configuration.

I do think there is a factual mismatch regarding the execution path described
in your reply. The validation raises fs.aio-max-nr to 2147483649 before
dropping privileges and calling io_setup(0x80000001). In that configuration:

  1. max_reqs retains 0x80000001.
  2. nr_events *= 2 wraps the request to 2.
  3. The wrapped value passes the ring-size check.
  4. aio_setup_ring() creates a one-page, 127-slot ring.
  5. aio_nr += ctx->max_reqs charges the original 0x80000001.
  6. ioctx_add_table() is called and succeeds.
  7. A subsequent normal io_setup(1) fails with -EAGAIN.

So, in this tested path, the ioctx is not destroyed before ioctx_alloc()
returns, and ioctx_add_table() is reached. The ring is small while the global
quota charge is large.

I agree that this is a low-value, configuration-dependent correctness issue,
not a security fix. My point is only that treating the configuration as
unsupported is different from saying the wrapped path is cleaned up before it
can be installed.

I will be more conservative about AI-assisted findings going forward and will
set a higher bar for preconditions, security impact, and whether a patch is
worth maintainer time. If you consider this configuration unsupported, I will
withdraw the patch.

Thanks,
Cheng