tcp: Fix sign comparison bug in getsockopt(TCP_ZEROCOPY_RECEIVE)
authorArjun Roy <arjunroy@google.com>
Thu, 25 Feb 2021 23:26:28 +0000 (15:26 -0800)
committerJakub Kicinski <kuba@kernel.org>
Fri, 26 Feb 2021 23:47:15 +0000 (15:47 -0800)
commit2107d45f17bedd7dbf4178462da0ac223835a2a7
tree680aee4d89414daf0508d548e09007de2f90e2ac
parent6a4d7234ae9a3bb31181f348ade9bbdb55aeb5c5
tcp: Fix sign comparison bug in getsockopt(TCP_ZEROCOPY_RECEIVE)

getsockopt(TCP_ZEROCOPY_RECEIVE) has a bug where we read a
user-provided "len" field of type signed int, and then compare the
value to the result of an "offsetofend" operation, which is unsigned.

Negative values provided by the user will be promoted to large
positive numbers; thus checking that len < offsetofend() will return
false when the intention was that it return true.

Note that while len is originally checked for negative values earlier
on in do_tcp_getsockopt(), subsequent calls to get_user() re-read the
value from userspace which may have changed in the meantime.

Therefore, re-add the check for negative values after the call to
get_user in the handler code for TCP_ZEROCOPY_RECEIVE.

Fixes: c8856c051454 ("tcp-zerocopy: Return inq along with tcp receive zerocopy.")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Arjun Roy <arjunroy@google.com>
Link: https://lore.kernel.org/r/20210225232628.4033281-1-arjunroy.kdev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net/ipv4/tcp.c