Crash in CLEAR_IF_FIRST handling in tdb

Rusty Russell rusty at
Fri Oct 5 00:24:44 MDT 2012

Volker Lendecke <Volker.Lendecke at SerNet.DE> writes:

> On Thu, Oct 04, 2012 at 10:03:58AM +0200, Volker Lendecke wrote:
>> > > Under
>> > >;a=shortlog;h=refs/heads/tdb
>> > > find a patchset that for me fixes a crash in winbind in tdb.
>> > > For the explanation, see the second patch from the top.
>> > 
>> > Good catch!
>> > 
>> > Your fix here should stop a crash when accessing the header, but the
>> > rest of the mmaped database is still going to cause SEGV, no?  We only
>> > re-map it when we see an offset which is out-of-bounds (vs the
>> > locally-cache tdb->map_size variable).
>> I believe we are okay with the fix. Whenever we access the
>> mmap area pointed to by the hash pointed to by the hash
>> sources, we lock the hash chain. I think we never keep
>> information beyond a F_UNLK. Because tdb_new_database
>> establishes an empty and correct database, tdb_fetch will
>> never randomly access memory beyond the current file limit.
>> The freelist is also set up with a short database in mind.
>> So whenever there is a need to go beyond the file size,
>> which might be shorter than the current mmap size, we will
>> end up in tdb_expand, which now should deal fine with a
>> shrunk file.
> Just updated the above branch with code that survived
> autobuild.

Oh, and the pread is a nice change
(f6270bb73a8981505194d7afbca2438e23b398e8), but conflicts with
libreplace's pread "replacement".

Should we just kill rep_pread?  Or at least fix it to restore the file


More information about the samba-technical mailing list