netdev - Re: Fw: [Bug 200215] New: UBSAN: Undefined behaviour in net/core/sock.c:LINE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 6 Jul 2018 14:43:42 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Subject: Re: Fw: [Bug 200215] New: UBSAN: Undefined behaviour in
 net/core/sock.c:LINE



On 07/06/2018 02:24 PM, Stephen Hemminger wrote:
> 
> 
> Begin forwarded message:
> 
> Date: Sat, 23 Jun 2018 00:00:25 +0000
> From: bugzilla-daemon@...zilla.kernel.org
> To: stephen@...workplumber.org
> Subject: [Bug 200215] New: UBSAN: Undefined behaviour in net/core/sock.c:LINE
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=200215
> 
>             Bug ID: 200215
>            Summary: UBSAN: Undefined behaviour in net/core/sock.c:LINE
>            Product: Networking
>            Version: 2.5
>     Kernel Version: v4.18-rc2
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Other
>           Assignee: stephen@...workplumber.org
>           Reporter: icytxw@...il.com
>         Regression: No
> 
> Hi,
> This bug was found in Linux Kernel v4.18-rc2
> 
> $ cat report4 
> ================================================================================
> UBSAN: Undefined behaviour in net/core/sock.c:793:19
> signed integer overflow:
> -1704733899 * 2 cannot be represented in type 'int'
> CPU: 0 PID: 5695 Comm: syz-executor1 Not tainted 4.18.0-rc1 #2
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x122/0x1c8 lib/dump_stack.c:113
>  ubsan_epilogue+0x12/0x86 lib/ubsan.c:159
>  handle_overflow+0x1c2/0x21f lib/ubsan.c:190
>  __ubsan_handle_mul_overflow+0x2a/0x38 lib/ubsan.c:214
>  sock_setsockopt+0x17f1/0x1c80 net/core/sock.c:793
>  __sys_setsockopt+0x23f/0x2a0 net/socket.c:1943
>  __do_sys_setsockopt net/socket.c:1958 [inline]
>  __se_sys_setsockopt net/socket.c:1955 [inline]
>  __x64_sys_setsockopt+0xcc/0x170 net/socket.c:1955
>  do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe

This seems harmless, a fix would be :

diff --git a/net/core/sock.c b/net/core/sock.c
index 03fdea5b0f575945a58fd14b546226d61ccd4988..9160f412d49dfe7706c202dbd531c247c0548a21 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -792,7 +792,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname,
                 * returning the value we actually used in getsockopt
                 * is the most desirable behavior.
                 */
-               sk->sk_rcvbuf = max_t(int, val * 2, SOCK_MIN_RCVBUF);
+               sk->sk_rcvbuf = max_t(int, val << 1, SOCK_MIN_RCVBUF);
                break;
 
        case SO_RCVBUFFORCE: