linux-kernel - Re: [PATCH] io_uring/rsrc: fix slab-out-of-bounds in io_buffer_register

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: <aUiC2615oUTgF_PT@kbusch-mbp>
Date: Mon, 22 Dec 2025 07:29:31 +0800
From: Keith Busch <kbusch@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: veygax <veyga@...gax.dev>, Ming Lei <ming.lei@...hat.com>,
	Jens Axboe <axboe@...nel.dk>,
	"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
	Caleb Sander Mateos <csander@...estorage.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] io_uring/rsrc: fix slab-out-of-bounds in
 io_buffer_register_bvec

On Thu, Dec 18, 2025 at 09:33:56PM -0800, Christoph Hellwig wrote:
> On Thu, Dec 18, 2025 at 08:56:43AM +0800, Keith Busch wrote:
> > On Thu, Dec 18, 2025 at 12:37:47AM +0000, veygax wrote:
> > > 	/*
> > > 	 * Add pages to bio manually.
> > > 	 * We use physically contiguous pages to trick blk_rq_nr_phys_segments
> > > 	 * into returning 1 segment.
> > > 	 * We use multiple bvec entries to trick the loop in io_buffer_register_bvec
> > > 	 * into writing out of bounds.
> > > 	 */
> > > 	for (i = 0; i < num_bvecs; i++) {
> > > 		struct bio_vec *bv = &bio->bi_io_vec[i];
> > > 		bv->bv_page = page + i;
> > > 		bv->bv_len = PAGE_SIZE;
> > > 		bv->bv_offset = 0;
> > > 		bio->bi_vcnt++;
> > > 		bio->bi_iter.bi_size += PAGE_SIZE;
> > > 	}
> > 
> > I believe you're supposed to use the bio_add_page() API rather than open
> > code the bvec setup.
> 
> The above is simply an open coded version of doing repeated
> __bio_add_page calls.  Which would be rather suboptimal, but perfectly
> valid.

Yeah, there's nothing stopping someone from using it that way, but a
quick survey of __bio_add_page() users appear to be special cases that
allocate a single vector bio, so its existing use is a short-cut that
bio_add_page() will inevitiably reach anyway. Did you intend for it to
be called directly for multiple vector uses too? It is suboptimal as you
said, so it still feels like a misuse if someone did that.