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
