Crash in CLEAR_IF_FIRST handling in tdb
Rusty Russell
rusty at rustcorp.com.au
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
>> > > http://git.samba.org/?p=vl/samba.git/.git;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
offset?
Thanks,
Rusty.
More information about the samba-technical
mailing list