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

[Wang Zhaolong]

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")
Is my understanding correct?

I look forward to hearing back.

Best regards,
Wang Zhaolong

> Hello,
>
> I was confused when reviewing the fix for CVE-2024-41001.
> To better understand the issue and the proposed solution, I would
> greatly appreciate your help in clarifying the following points:
>
> 1. What was the original patch that introduced this issue (any Fixes tag)?
> 2. Is the leaking variable member the "context->sockaddr"?
> 3. Could you shed some light on how the reference to the leaked memory is
>     lost during the transition from the prep phase to the issue phase?
> 4. The fix introduces a NOP operation "before the SQPOLL does anything."
>     How does this addition of a NOP operation prevent the memory leak from
>     occurring?
>
> Thank you in advance for taking the time to address my questions. Your
> insights will help me better understand this fix.
>
> Best regards,
> Wang Zhaolong
>
> > Description
> > ===========
> >
> > In the Linux kernel, the following vulnerability has been resolved:
> >
> > io_uring/sqpoll: work around a potential audit memory leak
> >
> > kmemleak complains that there's a memory leak related to connect
> > handling:
> >
> > unreferenced object 0xffff0001093bdf00 (size 128):
> > comm "iou-sqp-455", pid 457, jiffies 4294894164
> > hex dump (first 32 bytes):
> > 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00  ................
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > backtrace (crc 2e481b1a):
> > [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38
> > [<000000009c30bb45>] kmalloc_trace+0x228/0x358
> > [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138
> > [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8
> > [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4
> > [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48
> > [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4
> > [<00000000d999b491>] ret_from_fork+0x10/0x20
> >
> > which can can happen if:
> >
> > 1) The command type does something on the prep side that triggers an
> >     audit call.
> > 2) The thread hasn't done any operations before this that triggered
> >     an audit call inside ->issue(), where we have audit_uring_entry()
> >     and audit_uring_exit().
> >
> > Work around this by issuing a blanket NOP operation before the SQPOLL
> > does anything.
> >
> > The Linux kernel CVE team has assigned CVE-2024-41001 to this issue.