[bug #61144] [refer] bad validation of list in indexed biblography file

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?61144>

                 Summary: [refer] bad validation of list in indexed
biblography file
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Sat 11 Sep 2021 05:33:16 PM UTC
                Category: Preprocessor refer
                Severity: 2 - Minor
              Item Group: Incorrect behaviour
                  Status: In Progress
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

In groff 1.22.4, and probably every version going back to June 1991 at the
latest, we can observe a misleading diagnostic when performing validation
using the (undocumented) refer(1) `-V` option with an empty indexed
bibliography.

To create an empty indexed bibliography, create an empty file and index it
with indxbib(1).

Then use that bibliography as the database for preprocessing a document.

In both cases we will use the same input document and (empty, indexed)
bibliography.  Note how a misleading error diagnostic is produced when -V is
used.


$ > empty
$ indxbib empty # creates `empty.i`
$ cat > doc.roff
foo
.[
a
.]
$ REFER=empty refer doc.roff 
.lf 1 doc.roff
refer:doc.roff:4: warning: all keys would have been discarded in constructing
index 'empty.i'
refer:doc.roff:4: no matches for 'a'
foo\*([.1\*(.]
.ds [F 1
.]-
.][ 0 other
$ REFER=empty refer -V doc.roff 
.lf 1 doc.roff
refer:doc.roff:4: 'empty.i' is bad: last list element not negative
refer:doc.roff:4: no matches for 'a'
foo\*([.1\*(.]
.ds [F 1
.]-
.][ 0 other


The problem is not that the last list element was not negative, but rather
that the list _length_ was zero, so some data is read and misinterpreted.

I ran into this issue while studying a more serious problem with indexed
bibliographic database processing, wherein we fall prey to the the classic
problem of believing what a data file tells you about the sizes of the data
structures you should allocate[1], leading to a heap overread and segmentation
fault.

The problem is actually in
src/libs/libbib/index.cpp:index_search_item::verify.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716109






    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61144>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/