RSA-OAEP decoder accepts nonzero bytes inside the zero padding string

After unmasking OAEP's data block, the decoder verifies lHash and searches for the first 0x01 delimiter. It does not verify that every byte between lHash and that delimiter is zero. A data block containing arbitrary nonzero padding bytes is therefore accepted and its suffix returned as plaintext.

Vulnerable code

In cipher/rsa-common.c, function _gcry_rsa_oaep_decode:

failed |= ct_not_memequal (lhash, db, hlen);
for (n = n1 = hlen; n < db_len; n++)
  {
    not_found &= ct_not_equal_byte (db[n], 0x01);
    n1 += not_found;
  }
failed |= not_found;

Why it matters

OAEP requires DB to be lHash || PS || 0x01 || M with PS entirely zero. Accepting a larger language of encodings weakens strict ciphertext validation and can become useful if a protocol reveals success through output, errors, or timing. Constructing such an RSA ciphertext without the private key is not established here, so this finding is a decoder correctness flaw rather than a standalone decryption oracle.

Proposed fix

During the existing full-length scan, accumulate a constant-time failure bit for any byte that is neither zero while still before the first 0x01. Preserve the uniform scan and delayed error return. Add OAEP decode vectors with a nonzero byte at the start, middle, and end of PS, plus empty and valid PS cases, and check identical public error behavior for all malformed encodings.