On 2014/4/19 04:06, Bernd Schubert wrote:
While running FhGFS-to-NFS stress tests, I noticed this bug (with a RHEL 6.5 kernel, but I think it also in linux-git). [ 3428.087489] BUG: unable to handle kernel paging request at ffff880735fb8000 [ 3428.094821] IP: [<ffffffffa038066e>] nfsd4_create+0x27e/0x380 [nfsd] gdb resolves this to (gdb) l *(nfsd4_create+0x27e) 0x1469e is in nfsd4_create (fs/nfsd/nfs4proc.c:527). 522 * null-terminate by brute force, since at worst we 523 * will overwrite the first byte of the create namelen 524 * in the XDR buffer, which has already been extracted 525 * during XDR decode. 526 */ 527 create->cr_linkname[create->cr_linklen] = 0; 528 529 status = nfsd_symlink(rqstp, &cstate->current_fh, 530 create->cr_name, create->cr_namelen, 531 create->cr_linkname, create->cr_linklen, create->cr_linkname is set in nfsd4_decode_create and even current .git does not check for the result of savemem there. -- nfsd: nfsd4_decode_create: Fix a possible NULL pointer dereference From: Bernd Schubert <bernd.schubert@xxxxxxxxxxxxxxxxxx> create->cr_linkname was later used without any check if savemem() succeeded. Signed-off-by: Bernd Schubert <bernd.schubert@xxxxxxxxxxx> --- fs/nfsd/nfs4xdr.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c index 2723c1b..eb65d1e 100644 --- a/fs/nfsd/nfs4xdr.c +++ b/fs/nfsd/nfs4xdr.c @@ -603,6 +603,10 @@ nfsd4_decode_create(struct nfsd4_compoundargs *argp, struct nfsd4_create *create READ32(create->cr_linklen); READ_BUF(create->cr_linklen); SAVEMEM(create->cr_linkname, create->cr_linklen); + status = check_filename(create->cr_linkname, + create->cr_linklen);
Don't call check_filename() here. cr_linkname maybe a path contains '/', or '.', check_filename will return error nfserr_badname for those path. IMO, just check whether the length is zero as, if (create->cr_linklen == 0) return nfserr_inval; thanks, Kinglong Mee -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
