From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C30022D6FD for ; Mon, 18 Mar 2024 21:36:47 +0100 (CET) Received: (qmail 30026 invoked by uid 550); 18 Mar 2024 20:32:18 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28630 invoked from network); 18 Mar 2024 19:52:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710791812; x=1711396612; darn=lists.openwall.com; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=LDQiHmujam5s7hQBBTE+bSjeeWgQkPIysffwfV72yik=; b=k68UDK84/Eu+xMmc7sDZq9HHoAOzKjQftihyzLkEaDOXc3O/pL5F8mQZdvMuC9KuvJ uMqD+KvjUzgpPRpddOS/zGnQvIEoV7XrZ4BLfOXyPiteJKfSP3GwEaN4ZHANle54KIRk PtE8TKFGxUqnZYSzO2NQ4VnmpOuOv7DJDBq2zoaSpNYJ30HSCQ7nWcyUif2amjAevrsn veHOvRjUuM2m1m+oxHwqIb7gN69ptWNoexSFHgjw2WKlMyDO9JMcCWIyZN8THzp6L+S9 rReFYDn7Hf2c5hAb2n6/Lw/H6oNpvI3aIP78lHfkFFKrtUwKA/tEPNfN47rwjLBmmMmk bX6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710791812; x=1711396612; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=LDQiHmujam5s7hQBBTE+bSjeeWgQkPIysffwfV72yik=; b=uIed13HZv7KgGMbLqGT6IJqWniwj3+/SWRfLmSmP6Z4l2DF7MApBf7RS9TUw5SjWc+ x4Ov3+IOiqhCWWUCFl7DIwtRa58KPRhsyaYWtuyu4zBuEsUQ1JBQ+WWb+xcy8TISfmzv voV94vzekepfSZ5jc4FIvbUnw+YnA3hMbY8YkZGTrR0/rmWAP7U11s9+tR/LXGOLwbLt YzwoSCvz+WP+zw6QccsxMVlISd+aipSm/r1i/k5X3hUqu2KXwTtsMPAbdcoYURQsODZ3 nB8hgNRVyDUZu6QlEhadR2HLQbrHTAHKSGtRrGZuKdDYwWnn8GDoDCwtNTOtAMb+rJjs W33w== X-Gm-Message-State: AOJu0Yw0/lVJP4df+v60RL5RjyBMHg9OVYy+xmgM8U5lWvjzUeEul2re N8RSRgHtAuS6pnHYg97K5gpzH8r6fdPkwFBXJgEDzP4LQNLfR5yOkt6VVm0bNYU0WsiHZHMFh+j Txzp3bBMzCZ4xDLYmudhFiuiv2Lj5Nzq7fBA= X-Google-Smtp-Source: AGHT+IGqlUCS8BMPAkO4A7wCWX99NAPnmofHjSA0PmmemKui6IgSeWDz5g/5Xr2z96TBe4IAukGLgGFDiZrk0bEFz+U= X-Received: by 2002:a2e:2c05:0:b0:2d2:dfd6:8335 with SMTP id s5-20020a2e2c05000000b002d2dfd68335mr323178ljs.22.1710791812166; Mon, 18 Mar 2024 12:56:52 -0700 (PDT) MIME-Version: 1.0 From: Mike Cui Date: Mon, 18 Mar 2024 12:56:41 -0700 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000003fbbb00613f4c276" Subject: [musl] Potential bug in __res_msend_rc() wrt to union initialization. --0000000000003fbbb00613f4c276 Content-Type: text/plain; charset="UTF-8" I recently upgraded to clang-18, and after compiling musl with it, I noticed that all my getaddrinfo() calls are failing. I tracked this to be an issue in __res_msend_rc(), where the 'sin6' member of union 'sa' is initialized to garbage, rather than 0. Then later bind() fails with EADDRNOTAVAIL. I reported this bug on clang discourse: https://discourse.llvm.org/t/union-initialization-and-aliasing-clang-18-seems-to-miscompile-musl/77724, and the discussion seems to suggest that there is potentially a bug in musl as well. TL;DR: - According to strict interpretation of the C standard, initializing a union with '{0}', only initializes the first member of the union to 0 (in this case, sin4), and "default" initializes the rest. This interpretation is still up for debate. The proper way to initialize the entire union is '{ }' not '{ 0 }'. - There is currently a bug in clang-18 that treats '{ }' to be the same as '{ 0 }'. The proposed fix is to just zero out the entire union for both "{ 0 }" and "{ }". However we cannot rely on "{ 0 }" to always zero out the entire union in the future. musl should be fixed to use "{ }" for initialization. And to work around the current buggy release of clang-18, perhaps flip the order to make sin6 the first member of the struct? I've attached a patch that works for me. There may be other instances of the same bug in the musl code base. --- a/src/network/res_msend.c +++ b/src/network/res_msend.c @@ -83,9 +83,9 @@ int __res_msend_rc(int nqueries, const unsigned char *const *queries, int fd; int timeout, attempts, retry_interval, servfail_retry; union { - struct sockaddr_in sin; struct sockaddr_in6 sin6; - } sa = {0}, ns[MAXNS] = {{0}}; + struct sockaddr_in sin; + } sa = {}, ns[MAXNS] = {{}}; socklen_t sl = sizeof sa.sin; int nns = 0; int family = AF_INET; --0000000000003fbbb00613f4c276 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I recently upgraded to clang-18, and after compiling musl = with it, I noticed that all my getaddrinfo() calls are failing. I tracked t= his to be an issue in=C2=A0__res_msend_rc(), where the 'sin6' membe= r of union 'sa' is initialized to garbage, rather than 0. Then late= r bind() fails with=C2=A0EADDRNOTAVAIL.

I reported this = bug on clang discourse:=C2=A0https:= //discourse.llvm.org/t/union-initialization-and-aliasing-clang-18-seems-to-= miscompile-musl/77724, and the discussion seems to suggest that there i= s potentially a bug in musl as well. TL;DR:

- Acco= rding to strict interpretation of the C standard, initializing=C2=A0a union= with '{0}', only initializes the first member of the union to 0 (i= n this case, sin4), and "default" initializes the rest. This inte= rpretation is still up for debate. The proper way to initialize the entire = union is '{ }' not '{ 0 }'.
- There is currently = a bug in clang-18 that treats '{ }' to be the same as '{ 0 }= 9;. The proposed fix is to just zero out the entire union for both "{ = 0 }" and "{ }". However we cannot rely on "{ 0 }" = to always zero out the entire union in the future.

=
musl should be fixed to use "{ }" for initialization. And to= work around the current buggy release of clang-18, perhaps flip the order = to make sin6 the first member of the struct? I've attached a patch that= works for me. There may be other instances of the same bug in the musl cod= e base.

--- a/src/network/res_msend.c
+++ b/src= /network/res_msend.c
@@ -83,9 +83,9 @@ int __res_msend_rc(int nqueries, = const unsigned char *const *queries,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int fd;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int timeout, attempts, retry_interval, serv= fail_retry;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 union {
- =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct sockaddr_in sin;
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct sockaddr_in6 sin6;
- = =C2=A0 =C2=A0 =C2=A0 } sa =3D {0}, ns[MAXNS] =3D {{0}};
+ =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct sockaddr_in sin;
+ =C2=A0 =C2= =A0 =C2=A0 } sa =3D {}, ns[MAXNS] =3D {{}};
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = socklen_t sl =3D sizeof sa.sin;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int nns =3D = 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int family =3D AF_INET;
--0000000000003fbbb00613f4c276--