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

[Benjamin LaHaise]

aio_nr is never updated.  Your analysis is entirely incorrect.

		-ben

On Thu, Oct 22, 2026 at 08:44:06AM -0700, Cheng Yongkang wrote:
> 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
> 

-- 
"Thought is the essence of where you are now."