linux-kernel - Re: [PATCH] io_uring/rsrc: require cloned buffers to share accounting contexts

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <d6208848-ecb5-44df-9d68-8845cd25d1b6@kernel.dk>
Date: Tue, 14 Jan 2025 10:57:50 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Jann Horn <jannh@...gle.com>, Pavel Begunkov <asml.silence@...il.com>,
 io-uring@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] io_uring/rsrc: require cloned buffers to share accounting
 contexts

On 1/14/25 10:49 AM, Jann Horn wrote:
> When IORING_REGISTER_CLONE_BUFFERS is used to clone buffers from uring
> instance A to uring instance B, where A and B use different MMs for
> accounting, the accounting can go wrong:
> If uring instance A is closed before uring instance B, the pinned memory
> counters for uring instance B will be decremented, even though the pinned
> memory was originally accounted through uring instance A; so the MM of
> uring instance B can end up with negative locked memory.
> 
> Cc: stable@...r.kernel.org
> Closes: https://lore.kernel.org/r/CAG48ez1zez4bdhmeGLEFxtbFADY4Czn3CV0u9d_TMcbvRA01bg@mail.gmail.com
> Fixes: 7cc2a6eadcd7 ("io_uring: add IORING_REGISTER_COPY_BUFFERS method")
> Signed-off-by: Jann Horn <jannh@...gle.com>
> ---
> To be clear, I think this is a very minor issue, feel free to take your
> time landing it.
> 
> I put a stable marker on this, but I'm ambivalent about whether this
> issue even warrants landing a fix in stable - feel free to remove the
> Cc stable marker if you think it's unnecessary.

I'll just queue it up for 6.14. Let's just get it towards stable, if
nothing else it provides consistent behavior across kernels. IMHO that's
enough reason to move it to stable.

-- 
Jens Axboe