From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <v.shpilevoy@tarantool.org>
Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 7D69A469719
 for <tarantool-patches@dev.tarantool.org>;
 Tue,  3 Nov 2020 00:09:31 +0300 (MSK)
References: <FBB23D13-1A0D-4C92-918A-EB2995E2CB17@tarantool.org>
 <429b3e4d-490d-ea88-946a-fc0487f9e46a@tarantool.org>
 <20201102131945.GB517@tarantool.org>
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Message-ID: <fd5efc02-a732-ab08-d502-257140674ed6@tarantool.org>
Date: Mon, 2 Nov 2020 22:09:29 +0100
MIME-Version: 1.0
In-Reply-To: <20201102131945.GB517@tarantool.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [Tarantool-patches] [PATCH] core: fix static_alloc buffer
 overflow
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Sergey Ostanevich <sergos@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

> Thanks for the investigation! My bad, I used MIN as a function with
> sematics of all agruments calculated before call. You're right - in case
> of define it can cause a double call.
> 
> The SNPRINT although leaves some questions to me: in case 'written' is
> more or equal to 'size', it forces '_buf' to be set to NULL. But in the
> sio_socketname_to_buffer() there's no check for NULL between the calls.
> A call to snprintf() delivers a segfault, at least for Mac.

Woops, SNPRINT is used a lot in the code. If it is true, we need to fix SNPRINT.

> Also, factoring out 18 loc out of a function with a total of 24 seems
> redundant - IMVHO. 

With your patch it is also an issue with alignment. See below. I
tried to fix it in-place, but it was too ugly due to too big
indentation.

> --- a/src/lib/core/sio.c
> +++ b/src/lib/core/sio.c
> @@ -53,20 +53,22 @@ sio_socketname(int fd)
>         int save_errno = errno;
>         int name_size = 2 * SERVICE_NAME_MAXLEN;
>         char *name = static_alloc(name_size);
> -       int n = snprintf(name, name_size, "fd %d", fd);
> +       int to_be_printed = snprintf(name, name_size, "fd %d", fd);
> +       int n = MIN(to_be_printed, name_size);
>         if (fd >= 0) {
>                 struct sockaddr_storage addr;
>                 socklen_t addrlen = sizeof(addr);
>                 int rc = getsockname(fd, (struct sockaddr *) &addr, &addrlen);
>                 if (rc == 0) {
> -                       n += snprintf(name + n, name_size - n, ", aka %s",
> +                       to_be_printed = snprintf(name + n, name_size - n, ", aka %s",
>                                 sio_strfaddr((struct sockaddr *)&addr,
>                                                                 addrlen));

Here sio_strfaddr( should get +17 spaces, and that makes it hard
to read. So I extracted everything to a new function with lower
indentation.