linux-kernel - [PATCH] nfs: Fix security label length not being reset

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

Message-Id: <20200914154958.55451-1-jeffrey.mitchell@starlab.io>
Date:   Mon, 14 Sep 2020 10:49:57 -0500
From:   Jeffrey Mitchell <jeffrey.mitchell@...rlab.io>
To:     Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna.schumaker@...app.com>
Cc:     linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jeffrey Mitchell <jeffrey.mitchell@...rlab.io>
Subject: [PATCH] nfs: Fix security label length not being reset

nfs_readdir_page_filler() iterates over entries in a directory, reusing
the same security label buffer, but does not reset the buffer's length.
This causes decode_attr_security_label() to return -ERANGE if an entry's
security label is longer than the previous one's. This error, in
nfs4_decode_dirent(), only gets passed up as -EAGAIN, which causes another
failed attempt to copy into the buffer. The second error is ignored and
the remaining entries do not show up in ls, specifically the getdents64()
syscall.

Reproduce by creating multiple files in NFS and giving one of the later
files a longer security label. ls will not see that file nor any that are
added afterwards, though they will exist on the backend.

- Jeffrey

Jeffrey Mitchell (1):
  nfs: Fix security label length not being reset

 fs/nfs/dir.c | 3 +++
 1 file changed, 3 insertions(+)

-- 
2.25.1