The Ethernet standard specifies that all packets MUST be at least 46 bytes in length. IP packets don't have any such restriction (apart from the 20 bytes header) so they can be less than half the size of this requirement. In cases where the payload length is less than the minimum packet length, the rest of the Ethernet packet is supposed to be padded with 0s. Unfortunately, many NICs and drivers don't follow this standard. So what takes up the remaining bytes? That depends on the implementation of the driver and possibly the NIC.
In some case, this will be random data, similar to what you get when you access a buffer beyond its bounds in C. While unlikely, this may reveal sensitive information, such as a password in memory.
However, in some cases, a static buffer is used to send packets. Since each new packet is rewritten over the old one, there are parts of this buffer that contain an old packet. Usually this doesn't matter since it will only transmit as many bytes as there were in the packet copied to the buffer. However, when the number of bytes is under 46, it ends up sending part of the old packet.
Now the fun part. You can coerce any host to send a 46-byte Ethernet packet by sending an ICMP ping packet to the host. An ICMP ping packet with a 0-byte payload is 28 bytes long. Since a host returns the same size packet back, you'll get an extra 18 bytes from the previous packet. So, what can you get from these 18 bytes? Not usually a lot. In the worst case, you can get the first 18 bytes of a UDP packet just transmitted or a password stored somewhere in memory (which is feasible if a user just logged onto the system).
The scope of this attack is rather limited because it can only be executed against a host on the LAN, since the excess bytes will most likely be thrown away by routers if an attack is sent over the Internet. Additionally, since the TCP header is 26 bytes, it's not possible to intercept the payload of a TCP packet.