From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: building/using address-sanitizer-enabled emacs? Date: Wed, 10 May 2017 22:24:49 +0000 Message-ID: References: <83a86lbffk.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1141fbd6607606054f32f147" X-Trace: blaine.gmane.org 1494455115 7861 195.159.176.226 (10 May 2017 22:25:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 May 2017 22:25:15 +0000 (UTC) Cc: jim@meyering.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 11 00:25:11 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d8a2g-0001wU-N3 for ged-emacs-devel@m.gmane.org; Thu, 11 May 2017 00:25:11 +0200 Original-Received: from localhost ([::1]:45035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8a2m-0003g9-9Q for ged-emacs-devel@m.gmane.org; Wed, 10 May 2017 18:25:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8a2d-0003eX-2L for emacs-devel@gnu.org; Wed, 10 May 2017 18:25:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8a2a-00019n-Fm for emacs-devel@gnu.org; Wed, 10 May 2017 18:25:07 -0400 Original-Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:34710) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d8a2X-00016g-FB; Wed, 10 May 2017 18:25:01 -0400 Original-Received: by mail-wm0-x236.google.com with SMTP id u65so27186726wmu.1; Wed, 10 May 2017 15:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0CDjQmqm5B5T0Al3Xfs8xTa2vrC+qXXvjjRtenS+kiw=; b=KdwnPT/lBHW3i8GfV1zAWZ+zS22fT+3USHSAQcDDZHEhJCFACaafaZPweabcPonisq +3IxxEL7QDPLmGiEo3Kqc9xDtiPSpCCuQydrAlXDBfsWDFXyyrcgnQu8WYw0srb7JbZW BzMy8ZKDzqkKzEUIHmn98WvwY3eoC2Zf4h/Dm0wMRzarh5cfeGoTtFA/G2yTDIcO/HiU ZT5hplkw77EM2t/Zt3GJR/ssEq8/hkIBCUwVKFDBwn1kvfUnRCYaJlJrWZ8iqz57KJCy wWpR0PUtrCMy9UvTKvKly475jKeaocWSg8zzHVUJKLNliWlwSg451BSjAIGJsKHgK/mK ITqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0CDjQmqm5B5T0Al3Xfs8xTa2vrC+qXXvjjRtenS+kiw=; b=kKd1I2XXKJlza3DF7njyKM12XDfsl8ecARvArqP2i2bvK1x4l8T1ajJNEAoMZ/RUUz BxBlWicmWwIVorlm3X6pb4dab+fg4lIj6T8ZjvaX/H1aKBVRhk/FzWkvzMBkHiNzQHVf lZcAOIFWAubYhNJ/90khRnpfvJRMQUXa/n9e+Z/ah3FIWYSTrT0tBb1TX/bHvWGHdiU7 dJfgNnHZEPUIwp02Psi+xl8gZ56QIlwfI8z5TaZzgQy+pijifYOa+0dJChRo3IzmFXnv 7Bmr3TvAkxnXCYV2+3uJQ2TdOPwkibACjwvRLDAk+a8gardh+EYC664HeUnEOqMMHg4/ M30w== X-Gm-Message-State: AODbwcCrmaYkAV81XytaR10dsu7FiCeHf9dZ1HDAedSN5JF8FGlXIdaV wrUK9keGMXD+tsaU+WxoWxlCL145Rw== X-Received: by 10.28.172.69 with SMTP id v66mr1540391wme.46.1494455100141; Wed, 10 May 2017 15:25:00 -0700 (PDT) In-Reply-To: <83a86lbffk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214779 Archived-At: --001a1141fbd6607606054f32f147 Content-Type: text/plain; charset="UTF-8" Eli Zaretskii schrieb am Mi., 10. Mai 2017 um 04:43 Uhr: > > From: Philipp Stephani > > Date: Tue, 09 May 2017 23:15:26 +0000 > > > > There's one actual bug: the sockaddr_in in line 3538 of process.c needs > to be sockaddr_storage, otherwise > > it's too small for IPv6. (And conv_sockaddr_to_lisp should probably > check that the address is of the expected > > length and not blindly overwrite the len argument.) > > Please show the detailed analysis, as I looked into that once and > concluded that the code is correct. > The full report is ================================================================= ==31024==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5fbfa690 at pc 0x0001003e6baf bp 0x7fff5fbfa4f0 sp 0x7fff5fbfa4e8 READ of size 2 at 0x7fff5fbfa690 thread T0 #0 0x1003e6bae in conv_sockaddr_to_lisp src/process.c:2497:34 #1 0x1003eb9f8 in connect_network_socket src/process.c:3542:7 #2 0x1003e9864 in Fmake_network_process src/process.c:4154:5 #3 0x10035e417 in eval_sub src/eval.c:2191:10 #4 0x10035f1a7 in Fsetq src/eval.c:511:10 #5 0x10035dfd1 in eval_sub src/eval.c:2173:8 #6 0x10035efbf in Fprogn src/eval.c:449:13 #7 0x10035dfd1 in eval_sub src/eval.c:2173:8 #8 0x100361df4 in internal_lisp_condition_case src/eval.c:1297:24 #9 0x100361a85 in Fcondition_case src/eval.c:1221:10 #10 0x10035dfd1 in eval_sub src/eval.c:2173:8 #11 0x10035e02f in eval_sub src/eval.c:2208:21 #12 0x10035ef16 in Fand src/eval.c:384:13 #13 0x10035dfd1 in eval_sub src/eval.c:2173:8 #14 0x100360e44 in Fwhile src/eval.c:979:17 #15 0x10035dfd1 in eval_sub src/eval.c:2173:8 #16 0x10035efbf in Fprogn src/eval.c:449:13 #17 0x10035dfd1 in eval_sub src/eval.c:2173:8 #18 0x100361a28 in Funwind_protect src/eval.c:1185:9 #19 0x10035dfd1 in eval_sub src/eval.c:2173:8 #20 0x10035efbf in Fprogn src/eval.c:449:13 #21 0x100360d2c in Flet src/eval.c:963:9 #22 0x10035dfd1 in eval_sub src/eval.c:2173:8 #23 0x10035efbf in Fprogn src/eval.c:449:13 #24 0x10036766f in funcall_lambda src/eval.c:3015:11 #25 0x100364efb in Ffuncall src/eval.c:2746:11 #26 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #27 0x1003673de in funcall_lambda src/eval.c:2944:11 #28 0x100364efb in Ffuncall src/eval.c:2746:11 #29 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #30 0x1003673de in funcall_lambda src/eval.c:2944:11 #31 0x100364efb in Ffuncall src/eval.c:2746:11 #32 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #33 0x1003673de in funcall_lambda src/eval.c:2944:11 #34 0x100364efb in Ffuncall src/eval.c:2746:11 #35 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #36 0x1003673de in funcall_lambda src/eval.c:2944:11 #37 0x100364efb in Ffuncall src/eval.c:2746:11 #38 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #39 0x1003673de in funcall_lambda src/eval.c:2944:11 #40 0x100364efb in Ffuncall src/eval.c:2746:11 #41 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #42 0x1003673de in funcall_lambda src/eval.c:2944:11 #43 0x1003643df in apply_lambda src/eval.c:2881:9 #44 0x10035df97 in eval_sub src/eval.c:2265:12 #45 0x100363d85 in Feval src/eval.c:2042:28 #46 0x100366af0 in funcall_subr src/eval.c:2821:19 #47 0x100364f15 in Ffuncall src/eval.c:2744:11 #48 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #49 0x1003673de in funcall_lambda src/eval.c:2944:11 #50 0x100364efb in Ffuncall src/eval.c:2746:11 #51 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #52 0x1003673de in funcall_lambda src/eval.c:2944:11 #53 0x100364efb in Ffuncall src/eval.c:2746:11 #54 0x1003dd245 in exec_byte_code src/bytecode.c:641:12 #55 0x1003673de in funcall_lambda src/eval.c:2944:11 #56 0x1003643df in apply_lambda src/eval.c:2881:9 #57 0x10035df97 in eval_sub src/eval.c:2265:12 #58 0x100363d85 in Feval src/eval.c:2042:28 #59 0x10035e680 in eval_sub src/eval.c:2223:15 #60 0x1003a6944 in readevalloop src/lread.c:1947:15 #61 0x1003a410c in Fload src/lread.c:1359:7 #62 0x10035e917 in eval_sub src/eval.c:2234:15 #63 0x100363d85 in Feval src/eval.c:2042:28 #64 0x10026f0b2 in top_level_2 src/keyboard.c:1121:10 #65 0x1003621f4 in internal_condition_case src/eval.c:1326:25 #66 0x10026eaa4 in top_level_1 src/keyboard.c:1129:5 #67 0x100361411 in internal_catch src/eval.c:1091:25 #68 0x100249135 in command_loop src/keyboard.c:1090:2 #69 0x100248f21 in recursive_edit_1 src/keyboard.c:697:9 #70 0x100249480 in Frecursive_edit src/keyboard.c:768:3 #71 0x1002453a1 in main src/emacs.c:1687:3 #72 0x7fffae305234 in start (/usr/lib/system/libdyld.dylib:x86_64+0x5234) Address 0x7fff5fbfa690 is located in stack of thread T0 at offset 336 in frame #0 0x1003eabbf in connect_network_socket src/process.c:3307 This frame has 10 object(s): [32, 36) 'xerrno' [48, 52) 'family' [64, 68) 'optval' [80, 96) 'sa1' [112, 116) 'len1' [128, 132) 'len' [144, 272) 'fdset' [304, 308) 'rfamily' [320, 336) 'sa1261' <== Memory access at offset 336 overflows this variable [352, 356) 'len1262' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow src/process.c:2497:34 in conv_sockaddr_to_lisp Shadow bytes around the buggy address: 0x1fffebf7f480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffebf7f490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffebf7f4a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 0x1fffebf7f4b0: 04 f2 00 00 f2 f2 04 f2 04 f2 00 00 00 00 00 00 0x1fffebf7f4c0: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 04 f2 =>0x1fffebf7f4d0: 00 00[f2]f2 04 f3 f3 f3 00 00 00 00 00 00 00 00 0x1fffebf7f4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffebf7f4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1fffebf7f500: 00 00 00 00 f1 f1 f1 f1 00 00 05 f2 f2 f2 f2 f2 0x1fffebf7f510: 04 f2 00 f2 f2 f2 00 00 00 00 00 00 f2 f2 f2 f2 0x1fffebf7f520: 00 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 f3 f3 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==31024==ABORTING The problem is here: struct sockaddr_in sa1; socklen_t len1 = sizeof (sa1); if (getsockname (s, (struct sockaddr *)&sa1, &len1) == 0) contact = Fplist_put (contact, QClocal, conv_sockaddr_to_lisp ((struct sockaddr *)&sa1, len1)); sockaddr_in is too small for IPv6 addresses, so getsockname doesn't fill it out completely. But conv_sockaddr_to_lisp only looks at the address family and attempts to read out the entire IPv6 address, reading past the sa1 variable memory. Thus this needs to be sockaddr_storage, which is guaranteed to be large enough for all supported addresses. Probably there should also be an eassert(len1 <= sizeof sa1) after the call to getsockname, just to make sure. --001a1141fbd6607606054f32f147 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Mi., 10. Mai 2017 um 04:43=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 09 May 2017 23:15:26 +0000
>
> There's one actual bug: the sockaddr_in in line 3538 of process.c = needs to be sockaddr_storage, otherwise
> it's too small for IPv6. (And conv_sockaddr_to_lisp should probabl= y check that the address is of the expected
> length and not blindly overwrite the len argument.)

Please show the detailed analysis, as I looked into that once and
concluded that the code is correct.

The= full report is

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=3D=3D31024=3D=3DERROR: AddressSanitizer: stack-buff= er-overflow on address 0x7fff5fbfa690 at pc 0x0001003e6baf bp 0x7fff5fbfa4f= 0 sp 0x7fff5fbfa4e8
READ of size 2 at 0x7fff5fbfa690 thread T0
=C2=A0 =C2=A0 #0 0x1003e6bae in conv_sockaddr_to_lisp src/process.c= :2497:34
=C2=A0 =C2=A0 #1 0x1003eb9f8 in connect_network_socket s= rc/process.c:3542:7
=C2=A0 =C2=A0 #2 0x1003e9864 in Fmake_network= _process src/process.c:4154:5
=C2=A0 =C2=A0 #3 0x10035e417 in eva= l_sub src/eval.c:2191:10
=C2=A0 =C2=A0 #4 0x10035f1a7 in Fsetq sr= c/eval.c:511:10
=C2=A0 =C2=A0 #5 0x10035dfd1 in eval_sub src/eval= .c:2173:8
=C2=A0 =C2=A0 #6 0x10035efbf in Fprogn src/eval.c:449:1= 3
=C2=A0 =C2=A0 #7 0x10035dfd1 in eval_sub src/eval.c:2173:8
=C2=A0 =C2=A0 #8 0x100361df4 in internal_lisp_condition_case src/eval= .c:1297:24
=C2=A0 =C2=A0 #9 0x100361a85 in Fcondition_case src/ev= al.c:1221:10
=C2=A0 =C2=A0 #10 0x10035dfd1 in eval_sub src/eval.c= :2173:8
=C2=A0 =C2=A0 #11 0x10035e02f in eval_sub src/eval.c:2208= :21
=C2=A0 =C2=A0 #12 0x10035ef16 in Fand src/eval.c:384:13
=
=C2=A0 =C2=A0 #13 0x10035dfd1 in eval_sub src/eval.c:2173:8
= =C2=A0 =C2=A0 #14 0x100360e44 in Fwhile src/eval.c:979:17
=C2=A0 = =C2=A0 #15 0x10035dfd1 in eval_sub src/eval.c:2173:8
=C2=A0 =C2= =A0 #16 0x10035efbf in Fprogn src/eval.c:449:13
=C2=A0 =C2=A0 #17= 0x10035dfd1 in eval_sub src/eval.c:2173:8
=C2=A0 =C2=A0 #18 0x10= 0361a28 in Funwind_protect src/eval.c:1185:9
=C2=A0 =C2=A0 #19 0x= 10035dfd1 in eval_sub src/eval.c:2173:8
=C2=A0 =C2=A0 #20 0x10035= efbf in Fprogn src/eval.c:449:13
=C2=A0 =C2=A0 #21 0x100360d2c in= Flet src/eval.c:963:9
=C2=A0 =C2=A0 #22 0x10035dfd1 in eval_sub = src/eval.c:2173:8
=C2=A0 =C2=A0 #23 0x10035efbf in Fprogn src/eva= l.c:449:13
=C2=A0 =C2=A0 #24 0x10036766f in funcall_lambda src/ev= al.c:3015:11
=C2=A0 =C2=A0 #25 0x100364efb in Ffuncall src/eval.c= :2746:11
=C2=A0 =C2=A0 #26 0x1003dd245 in exec_byte_code src/byte= code.c:641:12
=C2=A0 =C2=A0 #27 0x1003673de in funcall_lambda src= /eval.c:2944:11
=C2=A0 =C2=A0 #28 0x100364efb in Ffuncall src/eva= l.c:2746:11
=C2=A0 =C2=A0 #29 0x1003dd245 in exec_byte_code src/b= ytecode.c:641:12
=C2=A0 =C2=A0 #30 0x1003673de in funcall_lambda = src/eval.c:2944:11
=C2=A0 =C2=A0 #31 0x100364efb in Ffuncall src/= eval.c:2746:11
=C2=A0 =C2=A0 #32 0x1003dd245 in exec_byte_code sr= c/bytecode.c:641:12
=C2=A0 =C2=A0 #33 0x1003673de in funcall_lamb= da src/eval.c:2944:11
=C2=A0 =C2=A0 #34 0x100364efb in Ffuncall s= rc/eval.c:2746:11
=C2=A0 =C2=A0 #35 0x1003dd245 in exec_byte_code= src/bytecode.c:641:12
=C2=A0 =C2=A0 #36 0x1003673de in funcall_l= ambda src/eval.c:2944:11
=C2=A0 =C2=A0 #37 0x100364efb in Ffuncal= l src/eval.c:2746:11
=C2=A0 =C2=A0 #38 0x1003dd245 in exec_byte_c= ode src/bytecode.c:641:12
=C2=A0 =C2=A0 #39 0x1003673de in funcal= l_lambda src/eval.c:2944:11
=C2=A0 =C2=A0 #40 0x100364efb in Ffun= call src/eval.c:2746:11
=C2=A0 =C2=A0 #41 0x1003dd245 in exec_byt= e_code src/bytecode.c:641:12
=C2=A0 =C2=A0 #42 0x1003673de in fun= call_lambda src/eval.c:2944:11
=C2=A0 =C2=A0 #43 0x1003643df in a= pply_lambda src/eval.c:2881:9
=C2=A0 =C2=A0 #44 0x10035df97 in ev= al_sub src/eval.c:2265:12
=C2=A0 =C2=A0 #45 0x100363d85 in Feval = src/eval.c:2042:28
=C2=A0 =C2=A0 #46 0x100366af0 in funcall_subr = src/eval.c:2821:19
=C2=A0 =C2=A0 #47 0x100364f15 in Ffuncall src/= eval.c:2744:11
=C2=A0 =C2=A0 #48 0x1003dd245 in exec_byte_code sr= c/bytecode.c:641:12
=C2=A0 =C2=A0 #49 0x1003673de in funcall_lamb= da src/eval.c:2944:11
=C2=A0 =C2=A0 #50 0x100364efb in Ffuncall s= rc/eval.c:2746:11
=C2=A0 =C2=A0 #51 0x1003dd245 in exec_byte_code= src/bytecode.c:641:12
=C2=A0 =C2=A0 #52 0x1003673de in funcall_l= ambda src/eval.c:2944:11
=C2=A0 =C2=A0 #53 0x100364efb in Ffuncal= l src/eval.c:2746:11
=C2=A0 =C2=A0 #54 0x1003dd245 in exec_byte_c= ode src/bytecode.c:641:12
=C2=A0 =C2=A0 #55 0x1003673de in funcal= l_lambda src/eval.c:2944:11
=C2=A0 =C2=A0 #56 0x1003643df in appl= y_lambda src/eval.c:2881:9
=C2=A0 =C2=A0 #57 0x10035df97 in eval_= sub src/eval.c:2265:12
=C2=A0 =C2=A0 #58 0x100363d85 in Feval src= /eval.c:2042:28
=C2=A0 =C2=A0 #59 0x10035e680 in eval_sub src/eva= l.c:2223:15
=C2=A0 =C2=A0 #60 0x1003a6944 in readevalloop src/lre= ad.c:1947:15
=C2=A0 =C2=A0 #61 0x1003a410c in Fload src/lread.c:1= 359:7
=C2=A0 =C2=A0 #62 0x10035e917 in eval_sub src/eval.c:2234:1= 5
=C2=A0 =C2=A0 #63 0x100363d85 in Feval src/eval.c:2042:28
=
=C2=A0 =C2=A0 #64 0x10026f0b2 in top_level_2 src/keyboard.c:1121:10
=C2=A0 =C2=A0 #65 0x1003621f4 in internal_condition_case src/eval.c= :1326:25
=C2=A0 =C2=A0 #66 0x10026eaa4 in top_level_1 src/keyboar= d.c:1129:5
=C2=A0 =C2=A0 #67 0x100361411 in internal_catch src/ev= al.c:1091:25
=C2=A0 =C2=A0 #68 0x100249135 in command_loop src/ke= yboard.c:1090:2
=C2=A0 =C2=A0 #69 0x100248f21 in recursive_edit_1= src/keyboard.c:697:9
=C2=A0 =C2=A0 #70 0x100249480 in Frecursive= _edit src/keyboard.c:768:3
=C2=A0 =C2=A0 #71 0x1002453a1 in main = src/emacs.c:1687:3
=C2=A0 =C2=A0 #72 0x7fffae305234 in start (/us= r/lib/system/libdyld.dylib:x86_64+0x5234)

Address = 0x7fff5fbfa690 is located in stack of thread T0 at offset 336 in frame
=C2=A0 =C2=A0 #0 0x1003eabbf in connect_network_socket src/process.c:= 3307

=C2=A0 This frame has 10 object(s):
=C2=A0 =C2=A0 [32, 36) 'xerrno'
=C2=A0 =C2=A0 [48, 52) &= #39;family'
=C2=A0 =C2=A0 [64, 68) 'optval'
=C2=A0 =C2=A0 [80, 96) 'sa1'
=C2=A0 =C2=A0 [112, 116) &#= 39;len1'
=C2=A0 =C2=A0 [128, 132) 'len'
=C2= =A0 =C2=A0 [144, 272) 'fdset'
=C2=A0 =C2=A0 [304, 308) &#= 39;rfamily'
=C2=A0 =C2=A0 [320, 336) 'sa1261' <=3D= =3D Memory access at offset 336 overflows this variable
=C2=A0 = =C2=A0 [352, 356) 'len1262'
HINT: this may be a false pos= itive if your program uses some custom stack unwind mechanism or swapcontex= t
=C2=A0 =C2=A0 =C2=A0 (longjmp and C++ exceptions *are* supporte= d)
SUMMARY: AddressSanitizer: stack-buffer-overflow src/process.c= :2497:34 in conv_sockaddr_to_lisp
Shadow bytes around the buggy a= ddress:
=C2=A0 0x1fffebf7f480: 00 00 00 00 00 00 00 00 00 00 00 0= 0 00 00 00 00
=C2=A0 0x1fffebf7f490: 00 00 00 00 00 00 00 00 00 0= 0 00 00 00 00 00 00
=C2=A0 0x1fffebf7f4a0: 00 00 00 00 00 00 00 0= 0 f1 f1 f1 f1 04 f2 04 f2
=C2=A0 0x1fffebf7f4b0: 04 f2 00 00 f2 f= 2 04 f2 04 f2 00 00 00 00 00 00
=C2=A0 0x1fffebf7f4c0: 00 00 00 0= 0 00 00 00 00 00 00 f2 f2 f2 f2 04 f2
=3D>0x1fffebf7f4d0: 00 0= 0[f2]f2 04 f3 f3 f3 00 00 00 00 00 00 00 00
=C2=A0 0x1fffebf7f4e0= : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=C2=A0 0x1fffeb= f7f4f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=C2=A0 0x= 1fffebf7f500: 00 00 00 00 f1 f1 f1 f1 00 00 05 f2 f2 f2 f2 f2
=C2= =A0 0x1fffebf7f510: 04 f2 00 f2 f2 f2 00 00 00 00 00 00 f2 f2 f2 f2
=C2=A0 0x1fffebf7f520: 00 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 f3 f3
Shadow byte legend (one shadow byte represents 8 application bytes= ):
=C2=A0 Addressable: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 00
=C2=A0 Partially addressable: 01 02 03 04 05 06 07=C2=A0
= =C2=A0 Heap left redzone: =C2=A0 =C2=A0 =C2=A0 fa
=C2=A0 Freed he= ap region: =C2=A0 =C2=A0 =C2=A0 fd
=C2=A0 Stack left redzone: =C2= =A0 =C2=A0 =C2=A0f1
=C2=A0 Stack mid redzone: =C2=A0 =C2=A0 =C2= =A0 f2
=C2=A0 Stack right redzone: =C2=A0 =C2=A0 f3
=C2= =A0 Stack after return: =C2=A0 =C2=A0 =C2=A0f5
=C2=A0 Stack use a= fter scope: =C2=A0 f8
=C2=A0 Global redzone: =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0f9
=C2=A0 Global init order: =C2=A0 =C2=A0 =C2=A0 f= 6
=C2=A0 Poisoned by user: =C2=A0 =C2=A0 =C2=A0 =C2=A0f7
=C2=A0 Container overflow: =C2=A0 =C2=A0 =C2=A0fc
=C2=A0 Array = cookie: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ac
=C2=A0 Intra = object redzone: =C2=A0 =C2=A0bb
=C2=A0 ASan internal: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 fe
=C2=A0 Left alloca redzone: =C2=A0 = =C2=A0 ca
=C2=A0 Right alloca redzone: =C2=A0 =C2=A0cb
= =3D=3D31024=3D=3DABORTING

The problem is here:

=C2=A0struct sockaddr_in sa1;
=C2=A0socklen_t len1 =3D sizeof= (sa1);
= =C2=A0if (getsockname (s, (struct sockaddr *)&sa1, &len1) = =3D=3D 0)
=C2=A0 =C2=A0contact =3D Fplist_put (contact, QClocal,
=C2= =A0conv_sockaddr_to_lisp ((struct sockaddr *)&sa1, len1));
sockaddr_in is too small for IPv6 addresses, so getsockname do= esn't fill it out completely. But conv_sockaddr_to_lisp only looks at t= he address family and attempts to read out the entire IPv6 address, reading= past the sa1 variable memory. Thus this needs to be sockaddr_storage, whic= h is guaranteed to be large enough for all supported addresses.
P= robably there should also be an eassert(len1 <=3D sizeof sa1) after the = call to getsockname, just to make sure.=C2=A0
--001a1141fbd6607606054f32f147--