Package: xapian-core / 1.4.3-2+deb9u3
Patch seriesview the series file
|fix unweighted and.patch | (download)||
2 1 + 1 - 0 !
fix incorrect results due to uninitialised memory The array holding max weight values in MultiAndPostList is never initialised if the operator is unweighted, but the values are still used to calculate the max weight to pass to subqueries, leading to incorrect results. This can be observed with an OR under an unweighted AND (e.g. OR under AND on the right side of AND_NOT). The fix applied is to simply default initialise this array, which should lead to a max weight of 0.0 being passed on to subqueries. Bug reported in notmuch by Kirill A. Shutemov, and forwarded by David Bremner.
|cve 2018 0499 mset snippet escaping.patch | (download)||
fix incomplete html escaping in mset::snippet() Characters <, > and & were escaped in some cases, but not all - this patch adds escaping in the missing cases. This issue has been allocated CVE-2018-0499.
|fix glass cursor bug.patch | (download)||
4 4 + 0 - 0 !
fix glass bug with writabledatabase cursors A long-lived cursor on a table in a WritableDatabase could get into an invalid state, which typically resulted in a DatabaseCorruptError being thrown with the message: . Db block overwritten - are there multiple writers? . But in fact the on-disk database is not corrupted - it's just that the cursor in memory has got into an inconsistent state. It looks like we'll always detect the inconsistency before it can cause on-disk corruption but it's hard to be complete certain. . The bug is in code to rebuild the cursor when the underlying table changes in ways which require that. That's a fairly rare occurrence (with my C++ reproducer it happens 99 times out of 5000 commits). . In chert the equivalent code just marks the cursor's blocks as not yet read, but in glass cursor blocks are reference counted and shared so we can't simply do that as it could affect other cursors sharing the same blocks. . So instead the glass code was leaving them with the contents they previously had, except for copying the current root block from the table's "built-in cursor". After the rebuild we seek the cursor to the same key it was on before, and that mostly works because we follow down each level in the Btree from the new root, except it can happen that the old cursor contained a block number which has since been released and reallocated, and in that case the block doesn't get reread and we try to use its old contents, which violates the rule that a parent can't be younger than its child and causes the exception. . This commit fixes this by simply resetting the rebuilt cursor to match the current "built-in cursor" at all levels (not just the root), which is cheap because of the reference counting. . Reported with a reproducer by Sylvain Taverne. Confirmed by David Bremner as fixing a problem in notmuch without a reduced reproducer.
|fix freelist leaks.patch | (download)||