summaryrefslogtreecommitdiff
path: root/drivers/hid
diff options
context:
space:
mode:
authorJeff Layton <jlayton@kernel.org>2022-08-01 15:57:26 -0400
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-08-17 14:22:47 +0200
commite9ba81ee1cbd4eb54c7b5a7b49ee272bf9bb62cb (patch)
tree1b3b013ba26692987e9aedae68bf3d6644ea64dd /drivers/hid
parentb437275e894b98a87d6f3fd8b58eefc9036b8eb6 (diff)
lockd: detect and reject lock arguments that overflow
commit 6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde upstream. 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+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/hid')
0 files changed, 0 insertions, 0 deletions