On March 10th, 2022, the Solidity team discovered a bug in the implementation of abi.encodeCall when used together with fixed-length bytes literals.
It was introduced together with abi.encodeCall in Solidity 0.8.11 and is fixed in 0.8.13.
We assigned the bug a severity of "very low".
Which Contracts are Affected?
You might be affected if you use abi.encodeCall(f, (...)) where f takes a bytesNN parameter and you provide the value for that parameter either as a hex literal (0x1234 or hex"abcd") or as a string literal ("abcd").
If you only pass variables to abi.encodeCall, your code is not affected.
Technical Details
The compiler did check that the types of the values are all implicitly convertible to the types of the parameters of the function (this was the main advantage of abi.encodeCall over abi.encode and the reason for adding the feature), but it did not take the types properly into account when generating the code for this function call. The generated code was still the same as the one for abi.encode, which just encodes according to the types of the arguments.
The problem is that literals like 0x1234 and "abcd" can be implicitly converted to different types: The first can be converted to both bytes2 and uint16 and the second can be converted to bytes4 and bytes memory.
In the first case, the compiler chose to encode 0x1234 as a uint16. This means it right-aligned it instead of left-aligning it for bytes2. In the second case, it was encoded as bytes memory, which is a dynamic type, and thus at the place of the bytes4 value, an offset pointer was stored and additional data was added at the end.
Since the bug is only present for literals (actual variables have proper types and implicit conversions are always no-ops), it should be easy to detect with simple testing.