From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-locales-return-6934-listarch-libc-locales=sources.redhat.com@sourceware.org>
Received: (qmail 120103 invoked by alias); 12 Dec 2019 15:58:34 -0000
Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-locales.sourceware.org>
List-Subscribe: <mailto:libc-locales-subscribe@sourceware.org>
List-Post: <mailto:libc-locales@sourceware.org>
List-Help: <mailto:libc-locales-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: libc-locales-owner@sourceware.org
Received: (qmail 120093 invoked by uid 89); 12 Dec 2019 15:58:33 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1032
X-HELO: us-smtp-1.mimecast.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1576166311;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=o+ke3MGvtPRDNQwtNYjkNDV/eUWqGd1qkt40+t3k/pQ=;
	b=eCuZeCAPL06mpoYhV+dZbmG2u0L0T/dyGHoMN+YSDDD2gZNO0lqXbmAI0Pktg4z+jvZ25x
	ej4D9e+GDMw/L5g15KHir5YVSGRr3vXkCiwHBMErtnsNlsywuyvkhCM0fbAWZbPEJVf6LY
	5E1zwKXgzVvUkBv24uA7AlkKk6Ho+Oo=
From: Florian Weimer <fweimer@redhat.com>
To: Abhidnya Joshi <abhidnyachirmule@gmail.com>
Cc: libc-locales@sourceware.org
Subject: Re: Crash in gconv_db.c
References: <CALmqtCWYWMUm51HhL0VM3YgBJagyC8T3uCGxiUCjXA0KBB-h8w@mail.gmail.com>
	<87bltiv10t.fsf@oldenburg2.str.redhat.com>
	<CALmqtCWfnPZ=B2=_VM=uqAgMWqh3FbGjxXLcbg466Tgct+dUVw@mail.gmail.com>
	<CALmqtCVBCb2vJ+XNb6WZa1csNZaisLmqoG5nTn-QUU0MO=UbPw@mail.gmail.com>
	<877e42cqfo.fsf@oldenburg2.str.redhat.com>
	<CALmqtCVKqf53j7=SbUA-k8jHu4AydsoFfN6SZVX8Hv=iYVBLuQ@mail.gmail.com>
	<CALmqtCU6KB6qu1c7R4ngZh=0v+jvqOVjUT431zJoVsKhiNQdbw@mail.gmail.com>
Date: Thu, 12 Dec 2019 15:58:00 -0000
In-Reply-To: <CALmqtCU6KB6qu1c7R4ngZh=0v+jvqOVjUT431zJoVsKhiNQdbw@mail.gmail.com>
	(Abhidnya Joshi's message of "Fri, 29 Nov 2019 00:17:42 +0530")
Message-ID: <875ziledsy.fsf@oldenburg2.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2019-q4/txt/msg00093.txt.bz2

* Abhidnya Joshi:

> In increment_counter function, do we have to handle integer overflow like=
 this?
>
>
> if (step->__counter =3D=3D INT_MAX)
> {
> step->__counter =3D 1
> }
> if (step->__counter++ =3D=3D 0)
> { ....
> }
>
> I do not understand what will be impact of this on different "steps".
> If step->__counter gets set to 0 and step->__modname is NULL
> then we see the segfault as mentioned earlier.

The steps array has reference counts in the array *elements*, which is
wrong.  We ran into this a couple of months ago when we tried to fix a
memory leak.  This is the reason why I have limited confidence in the
correctness of the reference counting.

I looked at what it would take to reproduce the overflow with repeated
iconv_open calls, and I estimate that 1.2 TiB of RAM are required, so I
have not reproduced that yet.

But there could be more subtle ways to trigger counter overflow, like
uselocale followed by pthread_exit.  Without a reproducer, we are in the
dark here unfortunately.

Thanks,
Florian