RSAES-PKCS1-v1_5 decoder accepts padding strings shorter than eight bytes

The RSAES-PKCS1-v1_5 decoder checks the block type and searches for a zero separator, but never requires the intervening padding string to contain at least eight nonzero bytes. Malformed encodings therefore pass structural validation and are returned as plaintext, contrary to PKCS #1.

Vulnerable code

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

n0 = n;
for (; n < nframe; n++)
  {
    not_found &= ct_not_equal_byte (frame[n], 0x00);
    n0 += not_found;
  }

failed |= not_found;
n0 += ct_is_zero (not_found);

Why it matters

The red/green vector 00 02 ff 00 followed by data was accepted even though its padding string is only one byte; adding a minimum-length check rejected it. This is a standards-validation defect in a security-sensitive decoder. Turning it into plaintext recovery still depends on how an application exposes success, errors, or timing, so the report does not claim a complete Bleichenbacher oracle by itself.

Proposed fix

Accumulate, without data-dependent early exits, whether the separator position leaves at least eight padding bytes after the block-type octet. Fold that condition into failed so all malformed cases retain uniform processing. Add vectors for padding lengths zero through nine, with and without the optional leading zero, and verify only lengths eight and above decode successfully.