]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
libctf: strtab corruption when strings are added to ctf_open()ed dicts
authorNick Alcock <nick.alcock@oracle.com>
Tue, 11 Jun 2024 18:37:54 +0000 (19:37 +0100)
committerNick Alcock <nick.alcock@oracle.com>
Tue, 18 Jun 2024 12:20:31 +0000 (13:20 +0100)
commit1cdcc977329d8729745ad5f1389a39b9dc423754
tree231fb8b36aa2fb9e8254bb270fb7ab859fb05f9b
parent28c812b34906c058a599924cc6ef399726c22cb9
libctf: strtab corruption when strings are added to ctf_open()ed dicts

ctf_str_add_ref and ctf_str_add_movable_ref take a string and are supposed
to return a strtab offset.  These offsets are "provisional": the ref
mechanism records the address of the location in which the ref is stored and
modifies it when the strtab is finally written out.  Provisional refs in new
dicts start at 0 and go up via strlen() as new refs are added: this is fine,
because the strtab is empty and none of these values will overlap any
existing string offsets (since there are none).  Unfortunately, when a dict
is ctf_open()ed, we fail to set the initial provisional strtab offset to a
higher value than any existing string offset: it starts at zero again!
It's a shame that we already *have* strings at those offsets...

This is all fixed up once the string is reserialized, but if you look up
newly-added strings before serialization, you get corrupted partial string
results from the existing ctf_open()ed dict.

Observed (and thus regtested) by an upcoming test (in this patch series).

Exposed by the recently-introduced series that permits modification of
ctf_open()ed dicts, which has not been released anywhere.  Before that,
any attempt to do such things would fail with ECTF_RDONLY.

libctf/
* ctf-string.c (ctf_str_create_atoms): Initialize
        ctf_str_prov_offset.
libctf/ctf-string.c