kernel/linux.git/net/sunrpc/xdr.c, branch linux-4.4.y

SUNRPC: Properly set the @subbuf parameter of xdr_buf_subsegment()

2020-06-30T00:08:04+00:00

commit 89a3c9f5b9f0bcaa9aea3e8b2a616fcaea9aad78 upstream. @subbuf is an output parameter of xdr_buf_subsegment(). A survey of call sites shows that @subbuf is always uninitialized before xdr_buf_segment() is invoked by callers. There are some execution paths through xdr_buf_subsegment() that do not set all of the fields in @subbuf, leaving some pointer fields containing garbage addresses. Subsequent processing of that buffer then results in a page fault. Signed-off-by: Chuck Lever Cc: Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman

SUNRPC: drop pointless static qualifier in xdr_get_next_encode_buffer()

2018-11-27T15:08:01+00:00

[ Upstream commit 025911a5f4e36955498ed50806ad1b02f0f76288 ] There is no need to have the '__be32 *p' variable static since new value always be assigned before use it. Signed-off-by: YueHaibing Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin

sunrpc: correct the computation for page_ptr when truncating

2018-11-21T08:27:44+00:00

commit 5d7a5bcb67c70cbc904057ef52d3fcfeb24420bb upstream. When truncating the encode buffer, the page_ptr is getting advanced, causing the next page to be skipped while encoding. The page is still included in the response, so the response contains a page of bogus data. We need to adjust the page_ptr backwards to ensure we encode the next page into the correct place. We saw this triggered when concurrent directory modifications caused nfsd4_encode_direct_fattr() to return nfserr_noent, and the resulting call to xdr_truncate_encode() corrupted the READDIR reply. Signed-off-by: Frank Sorenson Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

rpc: fix xdr_truncate_encode to handle buffer ending on page boundary

2015-01-07T19:03:58+00:00

A struct xdr_stream at a page boundary might point to the end of one page or the beginning of the next, but xdr_truncate_encode isn't prepared to handle the former. This can cause corruption of NFSv4 READDIR replies in the case that a readdir entry that would have exceeded the client's dircount/maxcount limit would have ended exactly on a 4k page boundary. You're more likely to hit this case on large directories. Other xdr_truncate_encode callers are probably also affected. Reported-by: Holger Hoffstätte Tested-by: Holger Hoffstätte Fixes: 3e19ce762b53 "rpc: xdr_truncate_encode" Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields

rpc: change comments to assertions

2014-10-23T18:05:11+00:00

Reported-by: Andrea Arcangeli Signed-off-by: J. Bruce Fields

RPC: remove unneeded checks from xdr_truncate_encode()

2014-10-23T18:05:11+00:00

Thanks to Andrea Arcangeli for pointing out these checks are obviously unnecessary given the preceding calculations. Reported-by: Andrea Arcangeli Signed-off-by: J. Bruce Fields

SUNRPC: xdr_get_next_encode_buffer should be declared static

2014-07-18T15:35:46+00:00

Quell another sparse warning. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields

nfsd4: simplify server xdr->next_page use

2014-06-06T23:22:46+00:00

The rpc code makes available to the NFS server an array of pages to encod into. The server represents its reply as an xdr buf, with the head pointing into the first page in that array, the pages ** array starting just after that, and the tail (if any) sharing any leftover space in the page used by the head. While encoding, we use xdr_stream->page_ptr to keep track of which page we're currently using. Currently we set xdr_stream->page_ptr to buf->pages, which makes the head a weird exception to the rule that page_ptr always points to the page we're currently encoding into. So, instead set it to buf->pages - 1 (the page actually containing the head), and remove the need for a little unintuitive logic in xdr_get_next_encode_buffer() and xdr_truncate_encode. Signed-off-by: J. Bruce Fields

rpc: define xdr_restrict_buflen

2014-05-30T21:32:01+00:00

With this xdr_reserve_space can help us enforce various limits. Signed-off-by: J. Bruce Fields

nfsd4: allow encoding across page boundaries

2014-05-30T21:31:54+00:00

After this we can handle for example getattr of very large ACLs. Read, readdir, readlink are still special cases with their own limits. Also we can't handle a new operation starting close to the end of a page. Signed-off-by: J. Bruce Fields