Up until now, av_aes_init() uses a->round_key[0].u8 + t
as dst of memcpy where it is intended for t to greater
than 16 (u8 is an uint8_t[16]); given that round_key itself
is an array, it is actually intended for the dst to be
in a latter round_key member. To do this properly,
just cast a->round_key to unsigned char*.
This fixes the srtp, aes, aes_ctr, mov-3elist-encrypted,
mov-frag-encrypted and mov-tenc-only-encrypted
FATE-tests with (Clang-)UBSan.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AES code uses av_aes_block, a union consisting of
uint64_t[2], uint32_t[4], uint8_t[4][4] and uint8_t[16].
subshift() performs byte-wise manipulations of two av_aes_blocks,
but when encrypting, it does so with a shift of two bytes;
more precisely, it uses
"av_aes_block *s1 = (av_aes_block *) (s0[0].u8 - s)"
and lateron uses the uint8_t[16] member to access s0.
Yet av_aes_block requires to be suitably aligned for
the uint64_t[2] member, which s0[0].u8 - 2 is certainly
not. This is in violation of 6.3.2.3 (7) of C11. UBSan
reports this in the aes_ctr, mov-3elist-encrypted,
mov-frag-encrypted, mov-tenc-only-encrypted and srtp
tests.
Furthermore, there is another issue here: The pointer points
outside of s0; this works, because all the accesses lateron
use an index >= 3. (Clang-)UBSan reports this as
"runtime error: index -2 out of bounds for type 'uint8_t[16]'".
This commit fixes both of these issues: The latter issue
is fixed by applying an offset of "+ 3" during the cast
and subtracting this from the indices used lateron.
The former issue is solved by not casting to av_aes_block*
at all; instead simply cast to unsigned char*.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some of these were made possible by moving several common macros to
libavutil/macros.h.
While just at it, also improve the other headers a bit.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These functions return an error typically when the key size is an
incorrect number. AVERROR(EINVAL) is more specific than -1.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This avoids a potential conflict with the equally named function from XOPEN
It also could reduce confusion in debugger backtraces
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
They are essential to be able to use the utils without av_malloc()
That is for example use with malloc(), memalign(), some other
private allocation function, on the stack or others.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The current API where the plain size is exposed is not of much
use - in most cases it is allocated dynamically anyway.
If allocated e.g. on the stack via an uint8_t array, there's no
guarantee that the struct's members are aligned properly (unless
the array is overallocated and the opaque pointer within it
manually aligned to some unspecified alignment).
Signed-off-by: Martin Storsjö <martin@martin.st>
For some of the code e.g. doing timing measurements there is no
real point in running regression testing on it, thus it should
not be counted against coverage.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Makes it give correct results with e.g. gcc 4.4.
For unknown reasons the generate asm code also changes
on e.g. gcc 4.3, making the code a bit larger but also
a bit faster.
Originally committed as revision 23896 to svn://svn.ffmpeg.org/ffmpeg/trunk
Andreas Rheinhardt
Michael Niedermayer
Diego Biurrun
Rodger Combs
Ganesh Ajjanagadde
Vittorio Giovara
Michael Niedermayer
Janne Grunau
Martin Storsjö
Reimar Döffinger
Alex Converse
Mans Rullgard
Aurelien Jacobs
Baptiste Coudurier