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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4457af52-01a2-be1b-9d13-486b6bd8e579@huawei.com>
Date: Thu, 18 Jul 2024 22:41:37 +0800
From: Wang Zhaolong <wangzhaolong1@...wei.com>
To: <cve@...nel.org>, <linux-kernel@...r.kernel.org>,
	<linux-cve-announce@...r.kernel.org>, <axboe@...nel.dk>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<io-uring@...r.kernel.org>
Subject: Re: CVE-2024-41001: io_uring/sqpoll: work around a potential audit
 memory leak

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.
>