poodle padding multiple blocks?
If the last byte in the block is larger than the block size, that would generate a padding error in SSL 3.0.

SSL 3.0 padding is up to $BlockSize-1$ bytes of unspecified data, and one byte with the length of the padding (not including the length byte itself).  TLS 1.0 and above allow padding longer than the block size, and requires that each byte contains the length.  The POODLE attack is against 3.0 (after downgrading the connection).

In the POODLE attack, you need to arrange two things, the length of the message (plus MAC) is exactly a multiple of the block size, and the byte you want to find out is moved to be the last byte in a block.

If you substitute the padding block with the block with the desired byte, it will occassionally (1 in 256) decode to be 15 (for a 128-bit block size), and the message will be accepted (because the padding byte now leads to a correct MAC, which is at the end of the previous block).  If it isn't accepted, generate a new encrypted message and try again (which will randomly change what that last byte decodes to, from any or all of a new key, a new IV, or any changed fields in the plaintext).

If you take the last byte, XOR it with the last byte of the previous block's ciphertext, then XOR it again with the last byte of the ciphertext preceding the original location of that block, you'll get the correct value of that byte.

Repeat after manipulating the plaintext so that another (unknown) byte is in the last byte of a block (without changing the required padding amount).

An earlier version of my answer was describing a Padding Oracle attack against PKCS#7 style padding, which relies on being able to distinguish between a padding error and a MAC error, the POODLE attack distinguishes between error and no error.

With TLS, padding can be longer than one block, and the implementation shouldn't distinguish between padding and MAC errors, but it's still susceptible to timing attacks, even if it calculates a MAC after detecting a padding error.