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