h.b.furuseth@usit.uio.no wrote:

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard

overlays/syncprov.c:syncprov_findcsn() sets an unchecked limit to 1. findcsn_cb() says /* We just want to know that at least one exists, so it's OK if * we exceed the unchecked limit or size limit. */

This looks like it can return a false positive if two or more other entries which the filter would eliminate have the same hash as the value syncprov searches for.

I don't believe this can cause any problem though. CSN indexing doesn't use a hash the way other indices do; the CSN timestamp is converted to binary form and saved as a 40 bit integer. Index collisions will only occur for multiple changes that occurred within the same 1-second interval.

The purpose of this search is to detect if a consumer's context CSN is stale, i.e., the provider no longer has any entries as old as the consumer's CSN. The fact that there is any index collision essentially proves that the CSN is not stale.

Also syncprov_findcsn() passes fc_limits uninitialized outside of the .lms_s_unchecked field to slapd. Valgrind complains in test018 about .lms_s_pr_hide in back-bdb/search.c:bdb_search(). Tested in HEAD.

Fixed in HEAD.