[1/2] ffmpeg: fix for CVE-2022-3964

A vulnerability classified as problematic has been found in ffmpeg. This affects an unknown part of the file
libavcodec/rpzaenc.c of the component QuickTime RPZA Video Encoder. The manipulation of the argument y_size
leads to out-of-bounds read. It is possible to initiate the attack remotely. The name of the patch is
92f9b28ed84a77138105475beba16c146bdaf984. It is recommended to apply a patch to fix this issue. The associated
identifier of this vulnerability is VDB-213543.

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2022-3964

Upstream Fix:
https://github.com/FFmpeg/FFmpeg/commit/92f9b28ed84a77138105475beba16c146bdaf984

Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
---
 ...c-stop-accessing-out-of-bounds-frame.patch | 89 +++++++++++++++++++
 .../recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb |  4 +-
 2 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch

Can you put a CVE tag in the patch header alongside your Upstream-Status and Signed-off-by?

We need this to track in an automated way that this patch deals with a specific CVE.

eg CVE: CVE-2022-3964

Ross

> On 23 Nov 2022, at 14:20, Narpat Mali via lists.openembedded.org <narpat.mali=windriver.com@lists.openembedded.org> wrote:
> 
> A vulnerability classified as problematic has been found in ffmpeg. This affects an unknown part of the file
> libavcodec/rpzaenc.c of the component QuickTime RPZA Video Encoder. The manipulation of the argument y_size
> leads to out-of-bounds read. It is possible to initiate the attack remotely. The name of the patch is
> 92f9b28ed84a77138105475beba16c146bdaf984. It is recommended to apply a patch to fix this issue. The associated
> identifier of this vulnerability is VDB-213543.
> 
> Reference:
> https://nvd.nist.gov/vuln/detail/CVE-2022-3964
> 
> Upstream Fix:
> https://github.com/FFmpeg/FFmpeg/commit/92f9b28ed84a77138105475beba16c146bdaf984
> 
> Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
> ---
> ...c-stop-accessing-out-of-bounds-frame.patch | 89 +++++++++++++++++++
> .../recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb |  4 +-
> 2 files changed, 92 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> 
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> new file mode 100644
> index 0000000000..2775a81cc8
> --- /dev/null
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> @@ -0,0 +1,89 @@
> +From 92f9b28ed84a77138105475beba16c146bdaf984 Mon Sep 17 00:00:00 2001
> +From: Paul B Mahol <onemda@gmail.com>
> +Date: Sat, 12 Nov 2022 16:12:00 +0100
> +Subject: [PATCH] avcodec/rpzaenc: stop accessing out of bounds frame
> +
> +Upstream-Status: Backport [https://github.com/FFmpeg/FFmpeg/commit/92f9b28ed84a77138105475beba16c146bdaf984]
> +
> +Signed-off-by: <narpat.mali@windriver.com>
> +
> +---
> + libavcodec/rpzaenc.c | 22 +++++++++++++++-------
> + 1 file changed, 15 insertions(+), 7 deletions(-)
> +
> +diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
> +index d710eb4f82..4ced9523e2 100644
> +--- a/libavcodec/rpzaenc.c
> ++++ b/libavcodec/rpzaenc.c
> +@@ -205,7 +205,7 @@ static void get_max_component_diff(const BlockInfo *bi, const uint16_t *block_pt
> + 
> +     // loop thru and compare pixels
> +     for (y = 0; y < bi->block_height; y++) {
> +-        for (x = 0; x < bi->block_width; x++){
> ++        for (x = 0; x < bi->block_width; x++) {
> +             // TODO:  optimize
> +             min_r = FFMIN(R(block_ptr[x]), min_r);
> +             min_g = FFMIN(G(block_ptr[x]), min_g);
> +@@ -278,7 +278,7 @@ static int leastsquares(const uint16_t *block_ptr, const BlockInfo *bi,
> +         return -1;
> + 
> +     for (i = 0; i < bi->block_height; i++) {
> +-        for (j = 0; j < bi->block_width; j++){
> ++        for (j = 0; j < bi->block_width; j++) {
> +             x = GET_CHAN(block_ptr[j], xchannel);
> +             y = GET_CHAN(block_ptr[j], ychannel);
> +             sumx += x;
> +@@ -325,7 +325,7 @@ static int calc_lsq_max_fit_error(const uint16_t *block_ptr, const BlockInfo *bi
> +     int max_err = 0;
> + 
> +     for (i = 0; i < bi->block_height; i++) {
> +-        for (j = 0; j < bi->block_width; j++){
> ++        for (j = 0; j < bi->block_width; j++) {
> +             int x_inc, lin_y, lin_x;
> +             x = GET_CHAN(block_ptr[j], xchannel);
> +             y = GET_CHAN(block_ptr[j], ychannel);
> +@@ -420,7 +420,9 @@ static void update_block_in_prev_frame(const uint16_t *src_pixels,
> +                                        uint16_t *dest_pixels,
> +                                        const BlockInfo *bi, int block_counter)
> + {
> +-    for (int y = 0; y < 4; y++) {
> ++    const int y_size = FFMIN(4, bi->image_height - bi->row * 4);
> ++
> ++    for (int y = 0; y < y_size; y++) {
> +         memcpy(dest_pixels, src_pixels, 8);
> +         dest_pixels += bi->rowstride;
> +         src_pixels += bi->rowstride;
> +@@ -730,14 +732,15 @@ post_skip :
> + 
> +             if (err > s->sixteen_color_thresh) { // DO SIXTEEN COLOR BLOCK
> +                 uint16_t *row_ptr;
> +-                int rgb555;
> ++                int y_size, rgb555;
> + 
> +                 block_offset = get_block_info(&bi, block_counter);
> + 
> +                 row_ptr = &src_pixels[block_offset];
> ++                y_size = FFMIN(4, bi.image_height - bi.row * 4);
> + 
> +-                for (int y = 0; y < 4; y++) {
> +-                    for (int x = 0; x < 4; x++){
> ++                for (int y = 0; y < y_size; y++) {
> ++                    for (int x = 0; x < 4; x++) {
> +                         rgb555 = row_ptr[x] & ~0x8000;
> + 
> +                         put_bits(&s->pb, 16, rgb555);
> +@@ -745,6 +748,11 @@ post_skip :
> +                     row_ptr += bi.rowstride;
> +                 }
> + 
> ++                for (int y = y_size; y < 4; y++) {
> ++                    for (int x = 0; x < 4; x++)
> ++                        put_bits(&s->pb, 16, 0);
> ++                }
> ++
> +                 block_counter++;
> +             } else { // FOUR COLOR BLOCK
> +                 block_counter += encode_four_color_block(min_color, max_color,
> +-- 
> +2.34.1
> +
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
> index a0c98d4ae0..43b858984b 100644
> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
> @@ -22,7 +22,9 @@ LIC_FILES_CHKSUM = "file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
>                     file://COPYING.LGPLv2.1;md5=bd7a443320af8c812e4c18d1b79df004 \
>                     file://COPYING.LGPLv3;md5=e6a600fd5e1d9cbde2d983680233ad02"
> 
> -SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz"
> +SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
> +           file://0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch"
> +
> SRC_URI[sha256sum] = "619e706d662c8420859832ddc259cd4d4096a48a2ce1eefd052db9e440eef3dc"
> 
> # Build fails when thumb is enabled: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
> -- 
> 2.34.1
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#173715): https://lists.openembedded.org/g/openembedded-core/message/173715
> Mute This Topic: https://lists.openembedded.org/mt/95218376/6875888
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ross.burton@arm.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Sure Ross, will make sure to add CVE tag in the patch header.

Do I need to send again this patch with CVE tag ?

Best Regards,
Narpat

Yes, please.


> On 29 Nov 2022, at 07:49, Mali, Narpat <Narpat.Mali@windriver.com> wrote:
> 
> Sure Ross, will make sure to add CVE tag in the patch header.
>  Do I need to send again this patch with CVE tag ?

Hi Ross,

As suggested, have sent both the patches again with CVE tag in patch header.

Best Regards,
Narpat

From: Ross Burton<mailto:Ross.Burton@arm.com>
Sent: 29 November 2022 19:12
To: Mali, Narpat<mailto:Narpat.Mali@windriver.com>
Cc: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>; Polampalli, Archana<mailto:Archana.Polampalli@windriver.com>; G Pillai, Hari<mailto:Hari.GPillai@windriver.com>
Subject: Re: [OE-core][PATCH 1/2] ffmpeg: fix for CVE-2022-3964

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

Yes, please.


> On 29 Nov 2022, at 07:49, Mali, Narpat <Narpat.Mali@windriver.com> wrote:
>
> Sure Ross, will make sure to add CVE tag in the patch header.
>  Do I need to send again this patch with CVE tag ?