[PATCH v2 0/2] packfile: fix corruption due to stale delta base cache entries

Hi,

this small patch series fixes the bug reported in [1].

To summarize: we never evict delta base cache entries when closing the owning pack. The cache may thus contain stale entries which are keyed by by the memory address of `struct packed_git` and the offset of the entry in the packfile. Now when allocating a new pack that happens to have the exact same address and that has entries sitting at the same offset, we may try to use these stale entries and thus yield corrupted data.

This all sounds very unlikely, but the interesting part is that this can be reproduced by using recursive merges with submodules, as we open and close the object databases of each respective submodule. And if they have similar packfiles, then we may trigger the bug.

The series is built on top of v2.56.0.

Changes in v2:
  - Commit message improvements.
  - Link to v1: https://patch.msgid.link/20261002-pks-packfile-stale-delta-base-cache-v1-0-7592a3e31ae0@pks.im

Thanks!

Patrick

[1]: <CAP4DsUexEmm1qo6jH+Qzy+n3dQs_OCJ8yg=ReF+aVrcTrC7NeQ@mail.gmail.com>

---
Patrick Steinhardt (2):
      packfile: move around `close_pack()`
      packfile: fix corruption due to stale delta base cache entries

 packfile.c                 | 33 ++++++++++++++++++++++----------
 t/t6437-submodule-merge.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 10 deletions(-)

Range-diff versus v1:

1:  e7c340df39 ! 1:  a8af6a79c7 packfile: move around `close_pack()`
    @@ Commit message
         packfile: move around `close_pack()`
     
         In the next commit we'll want to access the delta base cache in
    -    `close_pack()`. Move the function after the declaration of the cache to
    -    prepare for this.
    +    `close_pack()`. Move the function after the declaration of the cache so
    +    that we won't need a forward declaration.
     
         Signed-off-by: Patrick Steinhardt <ps@pks.im>
     
2:  25efe15034 ! 2:  d6d45b5bf9 packfile: fix corruption due to stale delta base cache entries
    @@ Commit message
         would have the exact same key.
     
         All of this sounds very theoretical, but we can actually trigger this
    -    bug somewhat reliably! When doing a merge with "--recurse-submodules" in
    -    a repository with lots of submodules that have similar-looking packfiles
    -    we end up opening and then closing the object databases of each of the
    -    submodules in sequence. Because of the above mentioned commit we would
    -    close and free each of the packfiles part of the respective databases,
    -    but we wouldn't evict thire delta base entries from the cache.
    +    bug somewhat reliably! When doing a merge in a repository with lots of
    +    submodules that have similar-looking packfiles we end up opening and
    +    then closing the object databases of each of the submodules in sequence.
    +    Because of the above mentioned commit we would close and free each of
    +    the packfiles part of the respective databases, but we wouldn't evict
    +    their delta base entries from the cache.
     
         When using glibc, one of the packfiles will eventually get the exact
         same address, and that will then cause Git to read the wrong entry from

--- base-commit: a018953688f1b10bddf91bff8747068f5f4746a4 change-id: 20261002-pks-packfile-stale-delta-base-cache-0d4730487643