WiredTiger writes two kinds of address cookies.

For regular block address cookies, the max cookie size is defined by WT_ADDR_MAX_COOKIE (in btmem.h) as 255 bytes. This is much larger than the actual size of current address cookies, which are made up of a small number of packed integers.

For checkpoint cookies, which include multiple block address cookies, the cookies size is defined by WT_BLOCK_CHECKPOINT_BUFFER (in block.h), which is defined as

(1 + 14 * WT_INTPACK64_MAXSIZE)

Or about 127 bytes.

These macros define the size of the memory buffers WT uses to read/write these cookies.

The problem is that if we ever used larger address cookies, allowed by WT_ADDR_MAX_COOKIE, we could wind up with checkpoint cookies that overflow buffers sized with WT_BLOCK_CHECKPOINT_BUFFER. (In my testing you can make this happen by adding 3 64-bit integers to the address cookie.)

The disaggregated block manager is using larger address cookies, so we are already facing some risk of this happening.

We should define the size of the checkpoint cookie in terms of the maximum size for regular address cookies.

As a secondary level of protection, there we should have a way to gracefully fail if we generate cookies that exceed these limits, rather than overflowing buffers and causing arbitrary corruption.