Re: CVE-2024-41001: io_uring/sqpoll: work around a potential audit memory leak

[Jens Axboe]

On 7/18/24 8:41 AM, Wang Zhaolong wrote:
> Hello,
> 
> I think a possible reason for the leak scenario is:
> 
> When `audit_context->dummy` is 0. __audit_sockaddr() allocates sockaddr.
> 
> In the below process, audit_reset_context() return early. ctx->sockaddr
> is not released.
> 
>   io_issue_sqe
>     audit_uring_entry
>       __audit_uring_entry
>         ctx->dummy -- set dummy as non-zero
>     def->issue()
>     audit_uring_exit
>       __audit_uring_exit
>         audit_reset_context
> 
> static void audit_reset_context(struct audit_context *ctx)
> {
>     ......
>     /* if ctx is non-null, reset the "ctx->context" regardless */
>     ctx->context = AUDIT_CTX_UNUSED;
>     if (ctx->dummy)
>         return;
> 
>     ......
>     kfree(ctx->sockaddr);
>     ......
> }
> 
> The `audit_uring_entry(IORING_OP_NOP);` statement initializes the 'dummy' once at the
> beginning to ensure that ctx->sockaddr is allocated and deallocated in pairs later
> in the process.
> 
> According to the above analysis, I think the fixes tag should be
> 5bd2182d58e9 ("audit,io_uring,io-wq: add some basic audit support to io_uring")

It was introduced with the changes to the above commit, where you could
end up calling prep (which does the move_addr_to_kernel()) before audit
was ready for it. This is the call trace shown in the commit as well.
Which I _think_ is:

Fixes: f482aa986527 ("audit, io_uring, io-wq: Fix memory leak in io_sq_thread() and io_wqe_worker()")

but I'd have to double check. In any case, it's a leak on the audit
side.

-- 
Jens Axboe