summaryrefslogtreecommitdiff
path: root/include/linux/lockd
diff options
context:
space:
mode:
authorJeff Layton <jlayton@kernel.org>2022-08-01 22:57:26 +0300
committerChuck Lever <chuck.lever@oracle.com>2022-08-04 17:28:48 +0300
commit6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde (patch)
tree82234eae589392283b24717de9ac2eac1845cb22 /include/linux/lockd
parentdd8dd403d7b223cc77ee89d8d09caf045e90e648 (diff)
downloadlinux-6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde.tar.xz
lockd: detect and reject lock arguments that overflow
lockd doesn't currently vet the start and length in nlm4 requests like it should, and can end up generating lock requests with arguments that overflow when passed to the filesystem. The NLM4 protocol uses unsigned 64-bit arguments for both start and length, whereas struct file_lock tracks the start and end as loff_t values. By the time we get around to calling nlm4svc_retrieve_args, we've lost the information that would allow us to determine if there was an overflow. Start tracking the actual start and len for NLM4 requests in the nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they won't cause an overflow, and return NLM4_FBIG if they do. Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=392 Reported-by: Jan Kasiak <j.kasiak@gmail.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Cc: <stable@vger.kernel.org> # 5.14+
Diffstat (limited to 'include/linux/lockd')
-rw-r--r--include/linux/lockd/xdr.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/include/linux/lockd/xdr.h b/include/linux/lockd/xdr.h
index 398f70093cd3..67e4a2c5500b 100644
--- a/include/linux/lockd/xdr.h
+++ b/include/linux/lockd/xdr.h
@@ -41,6 +41,8 @@ struct nlm_lock {
struct nfs_fh fh;
struct xdr_netobj oh;
u32 svid;
+ u64 lock_start;
+ u64 lock_len;
struct file_lock fl;
};