linux-kernel - Re: [PATCH net-next v10 08/16] tls: Inline do_tcp

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] [day] [month] [year] [list]

Message-ID: <3480243.1691672869@warthog.procyon.org.uk>
Date:   Thu, 10 Aug 2023 14:07:49 +0100
From:   David Howells <dhowells@...hat.com>
To:     Tariq Toukan <ttoukan.linux@...il.com>
Cc:     dhowells@...hat.com, Jakub Kicinski <kuba@...nel.org>,
        netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        David Ahern <dsahern@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Christoph Hellwig <hch@...radead.org>,
        Jens Axboe <axboe@...nel.dk>, Jeff Layton <jlayton@...nel.org>,
        Christian Brauner <brauner@...nel.org>,
        Chuck Lever III <chuck.lever@...cle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Boris Pismenny <borisp@...dia.com>,
        John Fastabend <john.fastabend@...il.com>,
        Gal Pressman <gal@...dia.com>, ranro@...dia.com,
        samiram@...dia.com, drort@...dia.com,
        Tariq Toukan <tariqt@...dia.com>
Subject: Re: [PATCH net-next v10 08/16] tls: Inline do_tcp_sendpages()

Tariq Toukan <ttoukan.linux@...il.com> wrote:

> We are collecting more info on how the repro is affected by the different
> parameters.

I'm wondering if userspace is feeding the unspliceable page in somehow.  Could
you try running with the attached changes?  It might help catch the point at
which the offending page is first spliced into the pipe and any backtrace
might help localise the driver that's producing it.

Thanks,
David
---
diff --git a/fs/splice.c b/fs/splice.c
index 3e2a31e1ce6a..877df1de3863 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -218,6 +218,8 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
 	while (!pipe_full(head, tail, pipe->max_usage)) {
 		struct pipe_buffer *buf = &pipe->bufs[head & mask];
 
+		WARN_ON_ONCE(!sendpage_ok(spd->pages[page_nr]));
+
 		buf->page = spd->pages[page_nr];
 		buf->offset = spd->partial[page_nr].offset;
 		buf->len = spd->partial[page_nr].len;
@@ -252,6 +254,8 @@ ssize_t add_to_pipe(struct pipe_inode_info *pipe, struct pipe_buffer *buf)
 	unsigned int mask = pipe->ring_size - 1;
 	int ret;
 
+	WARN_ON_ONCE(!sendpage_ok(buf->page));
+
 	if (unlikely(!pipe->readers)) {
 		send_sig(SIGPIPE, current, 0);
 		ret = -EPIPE;
@@ -861,6 +865,8 @@ ssize_t splice_to_socket(struct pipe_inode_info *pipe, struct file *out,
 				break;
 			}
 
+			WARN_ON_ONCE(!sendpage_ok(buf->page));
+
 			bvec_set_page(&bvec[bc++], buf->page, seg, buf->offset);
 			remain -= seg;
 			if (remain == 0 || bc >= ARRAY_SIZE(bvec))
@@ -1411,6 +1417,8 @@ static int iter_to_pipe(struct iov_iter *from,
 		for (i = 0; i < n; i++) {
 			int size = min_t(int, left, PAGE_SIZE - start);
 
+			WARN_ON_ONCE(!sendpage_ok(pages[i]));
+
 			buf.page = pages[i];
 			buf.offset = start;
 			buf.len = size;