linux-kernel - Re: iov_iter

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]

Date:   Thu, 27 Apr 2017 18:39:43 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Dave Jones <davej@...emonkey.org.uk>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: iov_iter_pipe warning.

On Thu, Apr 27, 2017 at 12:34:44PM -0400, Dave Jones wrote:

> [977286.117268] RPC request reserved 116 but used 268
> [1918138.126285] RPC request reserved 200 but used 268
> [2327777.483077] RPC request reserved 200 but used 268
> [2327800.909007] RPC request reserved 200 but used 268
> 
> related ?

Rather unlikely...  AFAICS, that's nfsd miscalculating the response
size and generating longer response than it has reserved.  The warning
comes from svc_xprt_release().  Out of its callers, svc_recv() is
impossible (it zeroes rqstp->rq_res.len before calling the sucker, so
there's no way for it to be found too large), which leaves svc_drop()
and svc_send().  The last one is more likely, AFAICS, and there the
length is calculated by
        /* calculate over-all length */
        xb = &rqstp->rq_res;
        xb->len = xb->head[0].iov_len +
                xb->page_len +
                xb->tail[0].iov_len;

Might be interesting to slap WARN_ON(xb->len > rqstp->rq_reserved); there
and see if it triggers.  Or something like
	if (WARN_ON(rqstp->rq_res->head[0].iov_len +
		rqstp->rq_res->page_len +
		rqstp->rq_res->tail[0].iov_len > rqstp->rq_reserved) {
		try to print something useful about request and response
	}
right before the call of ->xpo_release_rqst() in there - I hadn't looked
at that code for a long time, but it smells like dumping the request is
better done before the skbs containing it get dropped...