From patchwork Tue May 31 19:19:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 12657 Received: (qmail 10429 invoked by alias); 31 May 2016 19:19:17 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 10420 invoked by uid 89); 31 May 2016 19:19:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=carrying X-HELO: mail-qk0-f180.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=Zpnq0SqwToWwE9BGp8uG+xb2tDRTozmvye9ARhmDcq4=; b=Y3uRrI9Eff40UWlDNBeC8muaLFPCb4wr9nSQoal42y/fnJI26QRlwrsIDtPGaREs/Z yPPkQFxY0bqHtWh+lQgoyPqwKRivj9iUbEDn2PKHMR+JZ5ei1+MMpN14nGDyxoaoGZzz KbF8n4qG6J+N7UWYfNNLYhZKtuDJDDmm5uotr9uua1aTK0hCmR1HCMVPQmTHVKSW9+4G H6lXysQQmnZtbExf1V9kXB6GyzY4NONFcdcRGS+vuiggsTvpCkqyIrk/Gv1EDJy2i2YQ m99hHACg/ZA8kzh1ElAjsX2533PPEzuxt7mo/6JEDhLLWxjpHsLgSV9x4i8xiYugOemA 2nzw== X-Gm-Message-State: ALyK8tI3QBly5AdS1g/RDsDTQMwWy4Qg/wiYZaBoU8G+OvUtV0vnXuRPigxuVErBP0RzlxBg X-Received: by 10.237.44.162 with SMTP id g31mr32137658qtd.67.1464722353802; Tue, 31 May 2016 12:19:13 -0700 (PDT) To: Florian Weimer , GNU C Library From: Carlos O'Donell Subject: [WIP] resolv/res_send.c (__libc_res_nsend): Correctly sanity check buffer size. Message-ID: <574DE3AF.6010600@redhat.com> Date: Tue, 31 May 2016 15:19:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Florian, I had this sitting around in my tree as a fix I'd been carrying around but for one reason or another I never had a chance to push it. Given that the answer buffer is no longer being used for space to store two answers the "< 2 * HFIXEDSZ" possible outcome below is now overly conservative. We need only consider the case where (a) the buffer can't be reallocated (ansp is NULL) and (b) the size is less than HFIXEDSZ. For the second buffer we're always going to malloc enough space. Thoughts? diff --git a/resolv/res_send.c b/resolv/res_send.c index 869294f..3f42313 100644 --- a/resolv/res_send.c +++ b/resolv/res_send.c @@ -359,7 +359,9 @@ __libc_res_nsend(res_state statp, const u_char *buf, int buflen, return (-1); } - if (anssiz < (buf2 == NULL ? 1 : 2) * HFIXEDSZ) { + /* If the buffer can't be changed, and it's less than the + minimal header size, then that's an error. */ + if (anssiz < HFIXEDSZ && ansp == NULL) { __set_errno (EINVAL); return (-1); }