Opened 6 years ago
Closed 6 years ago
#8487 closed defect (fixed)
UBSan: left shift of negative value
| Reported by: | andreafioraldi | Owned by: | |
|---|---|---|---|
| Priority: | minor | Component: | avcodec |
| Version: | git-master | Keywords: | adpcm ubsan |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description (last modified by )
Build ffmpeg 4.2.2 using clang and ubsan (-fsanitize=undefined).
Command line: ./ffmpeg.ubsan -y -i ./input -c:v mpeg4 -c:a out.mp4
Output:
ffmpeg version 4.2.2 Copyright (c) 2000-2019 the FFmpeg developers
built with clang version 8.0.0-3~ubuntu18.04.2 (tags/RELEASE_800/final)
configuration: --cc=clang-8 --cxx=clang++-8 --ld=clang-8
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
Trailing options were found on the commandline.
[ea_cdata @ 0x902f600] Format ea_cdata detected only with low score of 12, misdetection possible!
Ignoring attempt to set invalid timebase 1/0 for st:0
libavcodec/adpcm.c:1415:50: runtime error: left shift of negative value -2
libavcodec/adpcm.c:1411:55: runtime error: left shift of negative value -1
[ea_cdata @ 0x902f600] decoding for stream 0 failed
[ea_cdata @ 0x902f600] Could not find codec parameters for stream 0 (Audio: adpcm_ea_xas, 1 channels, s16p): unspecified sample rate
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, ea_cdata, from './ffmpeg_ubsan_out/f1/crashes/id:000013,sig:04,src:001011+001703,time:2202546,op:splice,rep:16':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: adpcm_ea_xas, mono, s16p
At least one output file must be specified
Look at:
case AV_CODEC_ID_ADPCM_EA_XAS:
for (channel=0; channel<avctx->channels; channel++) {
...
val = sign_extend(bytestream2_get_le16u(&gb), 16);
shift[n] = 20 - (val & 0x0F);
...
}
for (m=2; m<32; m+=2) {
...
for (n = 0; n < 4; n++, s += 32) {
..
level = sign_extend(byte >> 4, 4) << shift[n]; //line 1415
...
}
}
}
This bug really does not make sense to me, val is controlled but the 0x0f mask should prevent to have a negative shift[n] value.
UBSan has no false positives, so there is a bug indeed, but I don't understand why.
Maybe there is something really bad with n indexes or some shady clang optimization that assumed bad things.
I attach a file to reproduce the issue in base64:
BAAAAABQX0UvBf//Bf93/3wIAAAAKAAAABBFMDAAABAATjs0MP93/1NBVUNFKTBtTncIAAAAE15BVV9FLzAMRm7/d/93B+4AACgAAABiRTAlOzQwbU47NCBtTgA=
Attachments (1)
Change History (4)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
| Description: | modified (diff) |
|---|---|
| Keywords: | adpcm added |
| Priority: | normal → minor |
| Reproduced by developer: | set |
| Status: | new → open |
| Version: | 4.2 → git-master |
by , 6 years ago
comment:3 by , 6 years ago
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
Fixed by Andreas Rheinhardt in 3ad8af51b7c0a968ac3fd62964780d4ff9136c5a



Okok sorry, sleepless saturday night, it is obviously sign_extend(byte >> 4, 4) that is negative, not shift[n].