Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <568A8CF3.9050707@apache.org>
Date: Mon, 04 Jan 2016 16:17:07 +0100
From: Stefan Fuhrmann <stefan2@apache.org>
Organization: Apache Software Foundation
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?SGFubm8gQsO2Y2s=?= <hanno@hboeck.de>
CC: dev@subversion.apache.org
Subject: Re: Invalid memory reads in first_non_fsm_start_char_cstring
 (utf_validate.c)
References: <20151219000359.4baf4691@pc1>	<567E751C.2030706@apache.org>
	<20160103154638.58ff9e8d@pc1>	<5689568F.4090702@apache.org>
 <20160103185031.1c1ef529@pc1>
In-Reply-To: <20160103185031.1c1ef529@pc1>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 03.01.2016 18:50, Hanno Böck wrote:
> On Sun, 3 Jan 2016 18:12:47 +0100
> Branko Čibej <brane@apache.org> wrote:
>
>> GCC (or any other compiler) may do a lot of things, but it's not
>> allowed to change the way APR pool allocation works. We're not using
>> malloc(); we're using apr_palloc() & co.
>
> Okay, I think we have a misunderstanding here.
>
> The error I encountered is not by code allocated by apr_palloc. It
> actually comes from this line in notify.c:
>    SVN_ERR(svn_dirent_get_absolute(&nb->path_prefix, "", pool));
>
> The memory that is read out of bounds is the "" string literal.

Yep, you are right.

Turns out that the whole code path was (almost) a duplication
of a function that does not have this problem. Fixed in r1722860.
A related problem was then found by our SOLARIS build bot and
got fixed in r1722879 and r1722887.

Thanks for the detailed report!

-- Stefan^2.