From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4D5494580C for ; Sun, 22 Oct 2023 18:35:48 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 576A868C9D1; Sun, 22 Oct 2023 21:35:46 +0300 (EEST) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4473368BA73 for ; Sun, 22 Oct 2023 21:35:40 +0300 (EEST) Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4084e49a5e5so22177135e9.3 for ; Sun, 22 Oct 2023 11:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1697999739; x=1698604539; darn=ffmpeg.org; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=nM3FuvxMS8tP4g9/85lmxlWENT3Q4MtFo+nQmB06W0Q=; b=Ud124i8p93hzFJX3JEpkD7lxlTicoDFxmF1uz8X6y0v1ciDUhS+87dVjIUbSxm+3Ge Q6AwZLpbBB81qxgs22VdMI4vEdAfnO+oquQFpP7bwgm8RCBefMT+K9tKXSSyp+kzqdrb M4P9tq3CjplPr0cu3rlGrgBO7EgnDNsD2LYkY9pYZMWQvC9UWlcaDojaZZ7fH93vXZLP shB3haeN4hu8JP2GCPZOTXXlu6ReQocQdc9a3wir6Fs3DVHfhog6FhhvLlgNmhg9a3J8 iuw02Npj5yxLgEhTUjUt2RlROL+OFxy8wQGsXSDwasgqY1G8WdIaytU93/TkybqhdvdP MJfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697999739; x=1698604539; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=nM3FuvxMS8tP4g9/85lmxlWENT3Q4MtFo+nQmB06W0Q=; b=Gkj4uJExSM/lCDIi2IubjJ/WrNb1nRBxPguYvwFiN8SLqXPZMytz7pLwm4H6RD7equ yGDamJlm4EpdISkOdo9VvjxTNsFdubDG2c6gDwpq0nn6l1vXLA+xOr80ppF/Sx8vKK+J kwekT7/aOrkyXz689BD65qE6ZlLQDY9fbRKs/YiUFJcXf+RkV2qaLgq54P6SD5BCR7XF D/NfVAQQ2MdWcrLllhgp6W/N21HinLd2Rd3L5X4MlLphWMh7S/AZ85N18NbWAMER31+b 0aNhnSgaRSzFK5KZWppak4GnB4lFiolcelntC4gKKOnaST0ScegwnVBFrbHusaJsXmtH B6rA== X-Gm-Message-State: AOJu0YzW9zQdeBv3u1+ENmvyfDXzoTkrdqBkjoZTp+QUCxs9oPS0kRI3 TAx3KZ4KhD46w9LlieUtlj3wVzVEx+5phou1IU0= X-Google-Smtp-Source: AGHT+IGWrkI/wcI5UCnxR3XLjCKqIX8CfPQwaEHKjIt4CWUVDqNf00nKNjieFzk9MpdjVx/jR4pv3w== X-Received: by 2002:a05:600c:3502:b0:408:40f3:22db with SMTP id h2-20020a05600c350200b0040840f322dbmr5358260wmq.6.1697999739314; Sun, 22 Oct 2023 11:35:39 -0700 (PDT) Received: from [192.168.0.15] (cpc92320-cmbg19-2-0-cust383.5-4.cable.virginm.net. [82.13.65.128]) by smtp.gmail.com with ESMTPSA id h17-20020a05600c499100b0040772138bb7sm12200606wmp.2.2023.10.22.11.35.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Oct 2023 11:35:39 -0700 (PDT) Message-ID: <259cfc93-3e34-4081-8640-82890edbf76a@jkqxz.net> Date: Sun, 22 Oct 2023 19:35:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: FFmpeg development discussions and patches From: Mark Thompson Subject: [FFmpeg-devel] [PATCH] cbs_av1: Reject thirty-two zero bits in uvlc code X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: The spec allows at least thirty-two zero bits followed by a one to mean 2^32-1, with no constraint on the number of zeroes. The libaom reference decoder does not match this, instead reading thirty-two zeroes but not the following one to mean 2^32-1. These two interpretations are incompatible and other implementations may follow one or the other. Therefore reject thirty-two zeroes because the intended behaviour is not clear. --- libaom, dav1d and SVT-AV1 all have the same nonstandard behaviour of stopping at thirty-two zeroes and not reading the one. gav1 just rejects thirty-two zeroes. This is also a source of arbitrarily large single syntax elements to hit . libavcodec/cbs_av1.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c index 1d9ac5ab44..13c749a25b 100644 --- a/libavcodec/cbs_av1.c +++ b/libavcodec/cbs_av1.c @@ -36,7 +36,7 @@ static int cbs_av1_read_uvlc(CodedBitstreamContext *ctx, GetBitContext *gbc, CBS_TRACE_READ_START(); zeroes = 0; - while (1) { + while (zeroes < 32) { if (get_bits_left(gbc) < 1) { av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid uvlc code at " "%s: bitstream ended.\n", name); @@ -49,10 +49,18 @@ static int cbs_av1_read_uvlc(CodedBitstreamContext *ctx, GetBitContext *gbc, } if (zeroes >= 32) { - // Note that the spec allows an arbitrarily large number of - // zero bits followed by a one bit in this case, but the - // libaom implementation does not support it. - value = MAX_UINT_BITS(32); + // The spec allows at least thirty-two zero bits followed by a + // one to mean 2^32-1, with no constraint on the number of + // zeroes. The libaom reference decoder does not match this, + // instead reading thirty-two zeroes but not the following one + // to mean 2^32-1. These two interpretations are incompatible + // and other implementations may follow one or the other. + // Therefore we reject thirty-two zeroes because the intended + // behaviour is not clear. + av_log(ctx->log_ctx, AV_LOG_ERROR, "Thirty-two zero bits in " + "%s uvlc code: considered invalid due to conflicting " + "standard and reference decoder behaviour.\n", name); + return AVERROR_INVALIDDATA; } else { if (get_bits_left(gbc) < zeroes) { av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid uvlc code at " -- 2.39.2 _______________________________________________ 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".