Skip to content

#4895: Fix integer overflow in EntryMemTable.getLastEntry - #4896

Open
djsweet wants to merge 1 commit into
apache:masterfrom
djsweet:djsweet/emt-lastentry-ledger-metadata
Open

djsweet wants to merge 1 commit into
apache:masterfrom
djsweet:djsweet/emt-lastentry-ledger-metadata

Conversation

@djsweet

@djsweet djsweet commented Sep 23, 2026

Copy link
Copy Markdown

Descriptions of the changes in this PR:

Fixes #4895.

Motivation

getLastEntry in EntryMemTable could return incorrect results if metadata (entries with negative entry IDs) is in use for the ledger. The KeyComparator used within EntryMemTable uses a simple subtraction for comparison, and when Long.MAX_VALUE was compared against a negative value (e.g. an explicit LAC entry), this would result in a long overflow, and incorrect comparison results.

Changes

The proposed fix here is to ensure that the comparison within getLastEntry does not ever hit an integer overflow condition, by having the floorKey comparison occur against a long value that can accommodate subtracting the lowest possible metadata ID (a subtraction of a negative value, ultimately becoming an addition) so that a long overflow does not occur.

This does reduce the highest possible entry ID within EntryMemTable by 32,768 as of this commit, but it seems incredibly unlikely that real world BookKeeper clusters will see entry IDs close to 2^64.

getLastEntry in EntryMemTable could return incorrect results if
metadata (entries with negative entry IDs) is in use for the
ledger. The KeyComparator used within EntryMemTable uses a
simple subtraction for comparison, and when Long.MAX_VALUE
was compared against a negative value (e.g. an explicit LAC
entry), this would result in a long overflow, and incorrect
comparison results.

The proposed fix here is to ensure that the comparison within
getLastEntry does not ever hit an integer overflow condition,
by having the floorKey comparison occur against a long value
that can accommodate subtracting the lowest possible metadata
ID (a subtraction of a negative value, ultimately becoming
an addition) so that a long overflow does not occur.

This does reduce the highest possible entry ID within
EntryMemTable by 32,768 as of this commit, but it seems
incredibly unlikely that real world BookKeeper clusters
will see entry IDs close to 2^64.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

EntryMemTable.getLastEntry reports incorrect last entry when ledger metadata is present

1 participant