View Issue Details

IDProjectCategoryView StatusLast Update
0018013CentOS-7kernelpublic2021-02-02 19:16
Reportercmdntrf Assigned To 
Status resolvedResolutionfixed 
Product Version7.9.2009 
Summary0018013: ls does not display some files on NFS 4.2 mount when SELinux labels are exported
DescriptionI have an NFS 4.2 export of /home with security label export enabled. When users create a file in their home directory, it does not show up in ls output unless they refer explictly to the file by its name.

The problem was introduced in kernel 3.10.0-1160.11.1.el7 and does not affect CentOS 8.
Steps To ReproduceOn an instance with SELinux enabled:

# Create a centos user if missing:
sudo useradd centos

# Export /home
cat << EOF | sudo tee /etc/exports
sudo systemctl start nfs-server

# Mount the export locally
sudo mkdir -p /mnt/nfs/home
sudo mount -t nfs localhost:/home /mnt/nfs/home/ -o vers=4.2

# Create a new file
sudo -u centos touch /mnt/nfs/home/centos/test

# File is missing from ls output
sudo -u centos ls -laZ /mnt/nfs/home/centos/

# File exist if refer by name
sudo -u centos ls -laZ /mnt/nfs/home/centos/test
Additional InformationIn kernel 3.10.0-1160.11.1.el7, the following patch was applied to fix a problem with nfs getxattr:

Reverting the patch and recompiling the kernel without it successfully fixed the issue, ls then displayed all files in the user's home.

I have narrowed down the issue to the patch of fs/nfs/nfs4xdr.c.

I have added the following printk call after the "if (label->len < len) {" :

printk(KERN_WARNING "%s: label too long (%u < %u)!\n", __func__, label->len, len);

The printk returned the following output when calling ls:
decode_attr_security_label: label too long (36 < 37)!

Therefore it appears the label is one byte too long and the function returns instead of copying the label successfully.
TagsNo tags attached.




2021-01-14 09:56

manager   ~0038174

It looks like the issue has been fixed upstream ( by :

commit d33030e2ee3508d65db5644551435310df86010e
Author: Jeffrey Mitchell <>
Date: Tue Sep 15 16:42:52 2020 -0500

    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()
    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.
    In nfs_readdir_page_filler(), reset security label buffer length before
    every reuse
    Signed-off-by: Jeffrey Mitchell <>
    Fixes: b4487b935452 ("nfs: Fix getxattr kernel panic and memory overflow")
    Signed-off-by: Trond Myklebust <>

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index e732580..cb52db9 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -579,6 +579,9 @@ int nfs_readdir_page_filler(nfs_readdir_descriptor_t *desc, struct nfs_entry
        xdr_set_scratch_buffer(&stream, page_address(scratch), PAGE_SIZE);
        do {
+ if (entry->label)
+ entry->label->len = NFS4_MAXLABELLEN;
                status = xdr_decode(desc, entry, &stream);
                if (status != 0) {
                        if (status == -EAGAIN)


2021-01-14 10:01

manager   ~0038175

The issue was reported for Fedora :

I cloned it for RHEL-7 : (private, like all other RHEL kernel bugs)


2021-01-23 09:34

manager   ~0038190

According to Red Hat, this issue is being worked on:

I think the patch will be in the next kernel update.


2021-02-02 00:43

manager   ~0038217

The fix will be in kernel-3.10.0-1160.15.2.el7.


2021-02-02 19:16

manager   ~0038218

The patch is in kernel-3.10.0-1160.15.2.el7 released today.

Issue History

Date Modified Username Field Change
2021-01-13 14:50 cmdntrf New Issue
2021-01-13 22:29 toracat Status new => acknowledged
2021-01-14 09:56 toracat Note Added: 0038174
2021-01-14 10:01 toracat Status acknowledged => assigned
2021-01-14 10:01 toracat Note Added: 0038175
2021-01-23 09:34 toracat Note Added: 0038190
2021-02-02 00:43 toracat Note Added: 0038217
2021-02-02 19:16 toracat Note Added: 0038218
2021-02-02 19:16 toracat Status assigned => resolved
2021-02-02 19:16 toracat Resolution open => fixed