_nfs4_get_security_label() and decode_attr_security_label() run severe risks with memory management and do not fully implement their functionality. In the case that the buffer and length are both NULL, which according to the getxattr man page should simply return the length of the attribute, decode_attr_security_label() will kernel panic trying to write to the null pointer. If the buffer length is nonzero but below the size of the attribute, decode_attr_security_label() will write the data anyway, overflowing the buffer, and it isn't until later in _nfs4_get_security_label() that -ERANGE gets returned. Here is some of the kernel panic output that I reproduced: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:__memcpy+0x12/0x20 [...] Call Trace: decode_getfattr_attrs+0xb1f/0xdc0 ? set_next_entity+0x8e/0x180 decode_getfattr_generic.constprop.0+0x10f/0x210 ? rpc_decode_header+0x570/0x570 nfs4_xdr_dec_getattr+0x94/0xa0 [...] _nfs4_get_security_label+0x134/0x180 ? _cond_resched+0x10/0x20 ? __kmalloc+0x1f6/0x200 nfs4_xattr_get_nfs4_label+0x89/0x120 __vfs_getxattr+0x4e/0x70 ecryptfs_getxattr_lower+0x4a/0x70 ecryptfs_xattr_get+0x23/0x24 __vfs_getxattr+0x4e/0x70 sb_finish_set_opts+0x12c/0x240 selinux_set_mnt_opts+0x288/0x6a0 security_sb_set_mnt_opts+0x40/0x60 vfs_get_tree+0x57/0xb0 do_mount+0x742/0x9b0 __x64_sys_mount+0x89/0xc0 do_syscall_64+0x3e/0x70 - Jeffrey Jeffrey Mitchell (1): nfs: Fix getxattr kernel panic and memory overflow fs/nfs/nfs4proc.c | 2 -- fs/nfs/nfs4xdr.c | 5 ++++- 2 files changed, 4 insertions(+), 3 deletions(-) -- 2.25.1
