OCB split AAD aborts when a buffered block becomes block 65,536

The split-input AAD path increments aad_nblocks after completing a buffered block. At the 65,536-block table boundary it correctly detects overflow, but asks ocb_get_L_big for aad_nblocks + 1. That helper requires a boundary-aligned block number, so the off-by-one request reaches an internal assertion and aborts the process.

Vulnerable code

In cipher/cipher-ocb.c, function _gcry_cipher_ocb_authenticate:

c->u_mode.ocb.aad_nblocks++;

if ((c->u_mode.ocb.aad_nblocks % table_maxblks) == 0)
  {
    /* Table overflow, L needs to be generated. */
    ocb_get_L_big(c, c->u_mode.ocb.aad_nblocks + 1, l_tmp);
  }

Why it matters

The red/green test first supplied 65,535 full blocks plus one byte, then the remaining 15 bytes. That ordinary split completes block 65,536 and reliably triggers the assertion; passing the current count instead made the test succeed. The total AAD is about one MiB, making the condition realistic wherever an attacker can control both AAD size and update boundaries. The impact is availability, not tag forgery.

Proposed fix

Pass c->u_mode.ocb.aad_nblocks to ocb_get_L_big in this buffered-block branch, matching the block actually being authenticated. Add regression vectors that compare one-shot and split AAD around blocks 65,535 through 65,537, including every possible split within the boundary block, and ensure tags match without assertions.