diff mbox series

[net] tcp: Fix sign comparison bug in getsockopt(TCP_ZEROCOPY_RECEIVE)

Message ID 20210225232628.4033281-1-arjunroy.kdev@gmail.com (mailing list archive)
State Accepted
Commit 2107d45f17bedd7dbf4178462da0ac223835a2a7
Delegated to: Netdev Maintainers
Headers show
Series [net] tcp: Fix sign comparison bug in getsockopt(TCP_ZEROCOPY_RECEIVE) | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net
netdev/subject_prefix success Link
netdev/cc_maintainers warning 3 maintainers not CCed: dsahern@kernel.org kuba@kernel.org yoshfuji@linux-ipv6.org
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 1 this patch: 1
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 9 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 1 this patch: 1
netdev/header_inline success Link
netdev/stable success Stable not CCed

Commit Message

Arjun Roy Feb. 25, 2021, 11:26 p.m. UTC 
From: Arjun Roy <arjunroy@google.com>

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>
---
 net/ipv4/tcp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

patchwork-bot+netdevbpf@kernel.org Feb. 26, 2021, 11:50 p.m. UTC | #1 
Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Thu, 25 Feb 2021 15:26:28 -0800 you wrote:
> From: Arjun Roy <arjunroy@google.com>
> 
> 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.
> 
> [...]

Here is the summary with links:
  - [net] tcp: Fix sign comparison bug in getsockopt(TCP_ZEROCOPY_RECEIVE)
    https://git.kernel.org/netdev/net/c/2107d45f17be

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
diff mbox series

Patch

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index a3422e42784e..dfb6f286c1de 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -4143,7 +4143,8 @@  static int do_tcp_getsockopt(struct sock *sk, int level,
 
 		if (get_user(len, optlen))
 			return -EFAULT;
-		if (len < offsetofend(struct tcp_zerocopy_receive, length))
+		if (len < 0 ||
+		    len < offsetofend(struct tcp_zerocopy_receive, length))
 			return -EINVAL;
 		if (unlikely(len > sizeof(zc))) {
 			err = check_zeroed_user(optval + sizeof(zc),