From: Karthik Nayak <karthik.188@xxxxxxxxx>
When migrating reflogs between reference backends, maintaining the
original order of the reflog entries is crucial. To achieve this, an
`index` field is stored within the `ref_update` struct that encodes the
relative order of reflog entries. This field is used by the reftable
backend as update index for the respective reflog entries to maintain
that ordering.
These update indices must be respected when writing table headers, which
encode the minimum and maximum update index of contained records in the
header and footer. This logic was added in commit bc67b4ab5f (reftable:
write correct max_update_index to header, 2025-01-15), which started to
use `reftable_writer_set_limits()` to propagate the mininum and maximum
update index of all records contained in a ref transaction.
However, we only set the maximum update index for the first transaction
argument, even though there can be multiple such arguments. This is the
case when we write to multiple stacks in a single transaction, e.g. when
updating references in two different worktrees at once. Consequently,
the update index for all but the first argument remain uninitialized,
which may cause undefined behaviour.
Fix this by moving the assignment of the maximum update index in
`reftable_be_transaction_finish()` inside the loop, which ensures that
all elements of the array are correctly initialized.
Furthermore, initialize the `max_index` field to 0 when queueing a new
transaction argument. This is not strictly necessary, as all elements of
`write_transaction_table_arg.max_index` are now assigned correctly.
However, this initialization is added for consistency and to safeguard
against potential future changes that might inadvertently introduce
uninitialized memory access.
Reported-by: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
Signed-off-by: Karthik Nayak <karthik.188@xxxxxxxxx>
Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
---
Hi,
Karthik is out of office this week, so I'm taking over this series for
him to ensure that it lands soonish. The only change compared to v3 is
an adapted commit message based on my own feedback.
Thanks!
Patrick
refs/reftable-backend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
index 289496058e..d39a14c5a4 100644
--- a/refs/reftable-backend.c
+++ b/refs/reftable-backend.c
@@ -1020,6 +1020,7 @@ static int prepare_transaction_update(struct write_transaction_table_arg **out,
arg->updates_nr = 0;
arg->updates_alloc = 0;
arg->updates_expected = 0;
+ arg->max_index = 0;
}
arg->updates_expected++;
@@ -1628,10 +1629,9 @@ static int reftable_be_transaction_finish(struct ref_store *ref_store UNUSED,
struct reftable_transaction_data *tx_data = transaction->backend_data;
int ret = 0;
- if (tx_data->args)
- tx_data->args->max_index = transaction->max_index;
-
for (size_t i = 0; i < tx_data->args_nr; i++) {
+ tx_data->args[i].max_index = transaction->max_index;
+
ret = reftable_addition_add(tx_data->args[i].addition,
write_transaction_table, &tx_data->args[i]);
if (ret < 0)
Range-diff against v3:
1: 614274cede ! 1: b7e3dd3cc8 refs: fix uninitialized memory access of `max_index`
@@ Metadata
Author: Karthik Nayak <karthik.188@xxxxxxxxx>
## Commit message ##
- refs: fix uninitialized memory access of `max_index`
+ refs/reftable: fix uninitialized memory access of `max_index`
When migrating reflogs between reference backends, maintaining the
original order of the reflog entries is crucial. To achieve this, an
- `index` field is stored within the `ref_update` struct.
+ `index` field is stored within the `ref_update` struct that encodes the
+ relative order of reflog entries. This field is used by the reftable
+ backend as update index for the respective reflog entries to maintain
+ that ordering.
- In the reftable backend, before writing any references, the writer must
- be configured with the minimum and maximum update index values. The
- `max_update_index` is derived from the maximum `ref_update.index` value
- in a transaction . The commit bc67b4ab5f (reftable: write correct
- max_update_index to header, 2025-01-15) addressed this by propagating the
- `max_update_index` value from the transaction to
- `write_transaction_table_arg` and, ultimately, to
- `reftable_writer_set_limits()`, which sets the min and max index for the
- reftable writer.
+ These update indices must be respected when writing table headers, which
+ encode the minimum and maximum update index of contained records in the
+ header and footer. This logic was added in commit bc67b4ab5f (reftable:
+ write correct max_update_index to header, 2025-01-15), which started to
+ use `reftable_writer_set_limits()` to propagate the mininum and maximum
+ update index of all records contained in a ref transaction.
- However, that commit introduced an issue:
+ However, we only set the maximum update index for the first transaction
+ argument, even though there can be multiple such arguments. This is the
+ case when we write to multiple stacks in a single transaction, e.g. when
+ updating references in two different worktrees at once. Consequently,
+ the update index for all but the first argument remain uninitialized,
+ which may cause undefined behaviour.
- - In `reftable_transaction_data`, which contains an array of
- `write_transaction_table_arg`, only the first element was assigned the
- `max_index` value.
+ Fix this by moving the assignment of the maximum update index in
+ `reftable_be_transaction_finish()` inside the loop, which ensures that
+ all elements of the array are correctly initialized.
- As a result, any elements beyond the first in the array contained
- uninitialized `max_index`. The writer contains multiple elements of
- `write_transaction_table_arg` to correspond to different worktrees being
- written. This uninitialized value was later used to set the
- `max_update_index` for the writer, potentially causing overflow or
- undefined behavior.
-
- Fix this by:
-
- - Initializing the `max_index` field to 0.
- - Moving the assignment of `max_index` in
- `reftable_be_transaction_finish()` inside the loop, ensuring all
- elements of the array are correctly initialized.
-
- Initializing `max_index` to `0` is not strictly necessary, as all
- elements of `write_transaction_table_arg.max_index` are now assigned
- correctly. However, this initialization is added for consistency and to
- safeguard against potential future changes that might inadvertently
- introduce uninitialized memory access.
+ Furthermore, initialize the `max_index` field to 0 when queueing a new
+ transaction argument. This is not strictly necessary, as all elements of
+ `write_transaction_table_arg.max_index` are now assigned correctly.
+ However, this initialization is added for consistency and to safeguard
+ against potential future changes that might inadvertently introduce
+ uninitialized memory access.
Reported-by: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
Signed-off-by: Karthik Nayak <karthik.188@xxxxxxxxx>
+ Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
## refs/reftable-backend.c ##
@@ refs/reftable-backend.c: static int prepare_transaction_update(struct write_transaction_table_arg **out,
--
2.48.1.362.g079036d154.dirty
