From: Thilo Borgmann <thilo.borgmann@mail.de>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavc/dovi_rpu: Fix UB for possible left shift of negative values
Date: Thu, 16 Jun 2022 12:22:40 +0200
Message-ID: <82d9a6ac-5365-dae4-9825-eabec6b2151f@mail.de> (raw)
In-Reply-To: <DB6PR0101MB22140B73859F0B240323E6A88FAC9@DB6PR0101MB2214.eurprd01.prod.exchangelabs.com>
[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]
Am 16.06.22 um 12:13 schrieb Andreas Rheinhardt:
> Thilo Borgmann:
>> diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
>> index a87562c8a3..833ce9e705 100644
>> --- a/libavcodec/dovi_rpu.c
>> +++ b/libavcodec/dovi_rpu.c
>> @@ -153,7 +153,7 @@ static inline uint64_t get_ue_coef(GetBitContext *gb, const AVDOVIRpuDataHeader
>> case RPU_COEFF_FIXED:
>> ipart = get_ue_golomb_long(gb);
>> fpart.u32 = get_bits_long(gb, hdr->coef_log2_denom);
>> - return (ipart << hdr->coef_log2_denom) + fpart.u32;
>> + return ipart * (1 << hdr->coef_log2_denom) + fpart.u32;
>>
>> case RPU_COEFF_FLOAT:
>> fpart.u32 = get_bits_long(gb, 32);
>> @@ -172,7 +172,7 @@ static inline int64_t get_se_coef(GetBitContext *gb, const AVDOVIRpuDataHeader *
>> case RPU_COEFF_FIXED:
>> ipart = get_se_golomb_long(gb);
>> fpart.u32 = get_bits_long(gb, hdr->coef_log2_denom);
>> - return (ipart << hdr->coef_log2_denom) + fpart.u32;
>> + return ipart * (1 << hdr->coef_log2_denom) + fpart.u32;
>>
>> case RPU_COEFF_FLOAT:
>> fpart.u32 = get_bits_long(gb, 32);
>
> coef_log2_denom can be in the range 13..32. This means that 1 <<
> hdr->coef_log2_denom can be UB (namely if coef_log2_denom is 31 or 32
> for ordinary 32 bit ints); this time it is not UB that happens to work
> as expected, because 1 << 32 will be 0 or 1 (depending upon the system)
> and not 2^32. In case of get_ue_coef() this actually adds UB to
> otherwise fine code.
So 1LL it needs to be, not? Am I still missing something?
V3 attached.
Thanks,
Thilo
[-- Attachment #2: v3-0001-lavc-dovi_rpu-Fix-UB-for-possible-left-shift-of-n.patch --]
[-- Type: text/plain, Size: 1496 bytes --]
From c3e4297983f8aa74b73df1ebf48a49b3cea736a7 Mon Sep 17 00:00:00 2001
From: Michael Goulet <mgoulet@fb.com>
Date: Thu, 16 Jun 2022 12:20:10 +0200
Subject: [PATCH v3] lavc/dovi_rpu: Fix UB for possible left shift of negative
values
It is undefined to left-shift a negative value.
Changed get_ue_coef() as well for consistency although its all positive values there.
---
libavcodec/dovi_rpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index a87562c8a3..ab14397ebd 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -153,7 +153,7 @@ static inline uint64_t get_ue_coef(GetBitContext *gb, const AVDOVIRpuDataHeader
case RPU_COEFF_FIXED:
ipart = get_ue_golomb_long(gb);
fpart.u32 = get_bits_long(gb, hdr->coef_log2_denom);
- return (ipart << hdr->coef_log2_denom) + fpart.u32;
+ return ipart * (1LL << hdr->coef_log2_denom) + fpart.u32;
case RPU_COEFF_FLOAT:
fpart.u32 = get_bits_long(gb, 32);
@@ -172,7 +172,7 @@ static inline int64_t get_se_coef(GetBitContext *gb, const AVDOVIRpuDataHeader *
case RPU_COEFF_FIXED:
ipart = get_se_golomb_long(gb);
fpart.u32 = get_bits_long(gb, hdr->coef_log2_denom);
- return (ipart << hdr->coef_log2_denom) + fpart.u32;
+ return ipart * (1LL << hdr->coef_log2_denom) + fpart.u32;
case RPU_COEFF_FLOAT:
fpart.u32 = get_bits_long(gb, 32);
--
2.20.1 (Apple Git-117)
[-- Attachment #3: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2022-06-16 10:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 8:59 Thilo Borgmann
2022-06-16 9:44 ` Andreas Rheinhardt
2022-06-16 10:04 ` Thilo Borgmann
2022-06-16 10:13 ` Andreas Rheinhardt
2022-06-16 10:22 ` Thilo Borgmann [this message]
2022-06-16 10:40 ` Andreas Rheinhardt
2022-06-16 11:19 ` Thilo Borgmann
2022-06-20 9:06 ` Thilo Borgmann
2022-06-21 16:24 ` Thilo Borgmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82d9a6ac-5365-dae4-9825-eabec6b2151f@mail.de \
--to=thilo.borgmann@mail.de \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git