Patch "io_uring/sqpoll: work around a potential audit memory leak" has been added to the 6.6-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    io_uring/sqpoll: work around a potential audit memory leak

to the 6.6-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     io_uring-sqpoll-work-around-a-potential-audit-memory.patch
and it can be found in the queue-6.6 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 36d2004025bd5b7ce72287118806a111cb544a7a
Author: Jens Axboe <axboe@xxxxxxxxx>
Date:   Thu Mar 21 07:38:38 2024 -0600

    io_uring/sqpoll: work around a potential audit memory leak
    
    [ Upstream commit c4ce0ab27646f4206a9eb502d6fe45cb080e1cae ]
    
    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.
    
    Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
index 65b5dbe3c850e..350436e55aafe 100644
--- a/io_uring/sqpoll.c
+++ b/io_uring/sqpoll.c
@@ -240,6 +240,14 @@ static int io_sq_thread(void *data)
 		sqd->sq_cpu = raw_smp_processor_id();
 	}
 
+	/*
+	 * Force audit context to get setup, in case we do prep side async
+	 * operations that would trigger an audit call before any issue side
+	 * audit has been done.
+	 */
+	audit_uring_entry(IORING_OP_NOP);
+	audit_uring_exit(true, 0);
+
 	mutex_lock(&sqd->lock);
 	while (1) {
 		bool cap_entries, sqt_spin = false;




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux