diff mbox series

[kirkstone,1/1] libwebp: Fix CVE-2023-4863

Message ID 20231031043732.2696809-1-soumya.sambu@windriver.com
State New, archived
Headers show
Series [kirkstone,1/1] libwebp: Fix CVE-2023-4863 | expand

Commit Message

Sambu, Soumya Oct. 31, 2023, 4:37 a.m. UTC
From: Soumya Sambu <soumya.sambu@windriver.com>

Heap buffer overflow in WebP in Google Chrome prior to
116.0.5845.187 allowed a remote attacker to perform an
out of bounds memory write via a crafted HTML page.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-4863
https://security-tracker.debian.org/tracker/CVE-2023-4863
https://bugzilla.redhat.com/show_bug.cgi?id=2238431#c12

Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
---
 .../webp/files/CVE-2023-4863.patch            | 109 ++++++++++++++++++
 meta/recipes-multimedia/webp/libwebp_1.2.4.bb |   1 +
 2 files changed, 110 insertions(+)
 create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-4863.patch

Comments

Mittal, Anuj Oct. 31, 2023, 4:55 a.m. UTC | #1
On Tue, 2023-10-31 at 04:37 +0000, Soumya via lists.openembedded.org
wrote:
> From: Soumya Sambu <soumya.sambu@windriver.com>
> 
> Heap buffer overflow in WebP in Google Chrome prior to
> 116.0.5845.187 allowed a remote attacker to perform an
> out of bounds memory write via a crafted HTML page.
> 
> References:
> https://nvd.nist.gov/vuln/detail/CVE-2023-4863
> https://security-tracker.debian.org/tracker/CVE-2023-4863
> https://bugzilla.redhat.com/show_bug.cgi?id=2238431#c12
> 
> Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
> ---
>  .../webp/files/CVE-2023-4863.patch            | 109
> ++++++++++++++++++
>  meta/recipes-multimedia/webp/libwebp_1.2.4.bb |   1 +
>  2 files changed, 110 insertions(+)
>  create mode 100644 meta/recipes-multimedia/webp/files/CVE-2023-
> 4863.patch
> 
> diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch
> b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch
> new file mode 100644
> index 0000000000..4c60cbc9a1
> --- /dev/null
> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch
> @@ -0,0 +1,109 @@
> +From 95ea5226c870449522240ccff26f0b006037c520 Mon Sep 17 00:00:00
> 2001
> +From: Vincent Rabaud <vrabaud@google.com>
> +Date: Mon, 11 Sep 2023 16:06:08 +0200
> +Subject: [PATCH] Fix invalid incremental decoding check.
> +
> +The first condition is only necessary if we have not read enough
> +(enough being defined by src_last, not src_end which is the end
> +of the image).
> +The second condition now fits the comment below: "if not
> +incremental, and we are past the end of buffer".
> +
> +BUG=oss-fuzz:62136
> +
> +Change-Id: I0700f67c62db8e1c02c2e429a069a71e606a5e4f
> +
> +CVE: CVE-2023-4863
> +
> +Upstream-Status: Backport
> [https://github.com/webmproject/libwebp/commit/95ea5226c870449522240c
> cff26f0b006037c520]
> +
> +Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
> +---
> + ...x-invalid-incremental-decoding-check.patch | 48
> +++++++++++++++++++

Patch file included by mistake?

Thanks,

Anuj

> + src/dec/vp8l_dec.c                            | 15 +++++-
> + 2 files changed, 61 insertions(+), 2 deletions(-)
> + create mode 100644 0001-Fix-invalid-incremental-decoding-
> check.patch
> +
> +diff --git a/0001-Fix-invalid-incremental-decoding-check.patch
> b/0001-Fix-invalid-incremental-decoding-check.patch
> +new file mode 100644
> +index 0000000..21f67f4
> +--- /dev/null
> ++++ b/0001-Fix-invalid-incremental-decoding-check.patch
> +@@ -0,0 +1,48 @@
> ++From 95ea5226c870449522240ccff26f0b006037c520 Mon Sep 17 00:00:00
> 2001
> ++From: Vincent Rabaud <vrabaud@google.com>
> ++Date: Mon, 11 Sep 2023 16:06:08 +0200
> ++Subject: [PATCH] Fix invalid incremental decoding check.
> ++
> ++The first condition is only necessary if we have not read enough
> ++(enough being defined by src_last, not src_end which is the end
> ++of the image).
> ++The second condition now fits the comment below: "if not
> ++incremental, and we are past the end of buffer".
> ++
> ++BUG=oss-fuzz:62136
> ++
> ++Change-Id: I0700f67c62db8e1c02c2e429a069a71e606a5e4f
> ++---
> ++ src/dec/vp8l_dec.c | 15 +++++++++++++--
> ++ 1 file changed, 13 insertions(+), 2 deletions(-)
> ++
> ++diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
> ++index 5ab34f56..809b1aa9 100644
> ++--- a/src/dec/vp8l_dec.c
> +++++ b/src/dec/vp8l_dec.c
> ++@@ -1233,9 +1233,20 @@ static int DecodeImageData(VP8LDecoder*
> const dec, uint32_t* const data,
> ++   }
> ++
> ++   br->eos_ = VP8LIsEndOfStream(br);
> ++-  if (dec->incremental_ && br->eos_ && src < src_end) {
> +++  // In incremental decoding:
> +++  // br->eos_ && src < src_last: if 'br' reached the end of the
> buffer and
> +++  // 'src_last' has not been reached yet, there is not enough
> data. 'dec' has to
> +++  // be reset until there is more data.
> +++  // !br->eos_ && src < src_last: this cannot happen as either the
> buffer is
> +++  // fully read, either enough has been read to reach 'src_last'.
> +++  // src >= src_last: 'src_last' is reached, all is fine. 'src'
> can actually go
> +++  // beyond 'src_last' in case the image is cropped and an LZ77
> goes further.
> +++  // The buffer might have been enough or there is some left. 'br-
> >eos_' does
> +++  // not matter.
> +++  assert(!dec->incremental_ || (br->eos_ && src < src_last) || src
> >= src_last);
> +++  if (dec->incremental_ && br->eos_ && src < src_last) {
> ++     RestoreState(dec);
> ++-  } else if (!br->eos_) {
> +++  } else if ((dec->incremental_ && src >= src_last) || !br->eos_)
> {
> ++     // Process the remaining rows corresponding to last row-block.
> ++     if (process_func != NULL) {
> ++       process_func(dec, row > last_row ? last_row : row);
> ++--
> ++2.40.0
> ++
> +diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
> +index 186b0b2..59a9e64 100644
> +--- a/src/dec/vp8l_dec.c
> ++++ b/src/dec/vp8l_dec.c
> +@@ -1241,9 +1241,20 @@ static int DecodeImageData(VP8LDecoder* const
> dec, uint32_t* const data,
> +   }
> +
> +   br->eos_ = VP8LIsEndOfStream(br);
> +-  if (dec->incremental_ && br->eos_ && src < src_end) {
> ++  // In incremental decoding:
> ++  // br->eos_ && src < src_last: if 'br' reached the end of the
> buffer and
> ++  // 'src_last' has not been reached yet, there is not enough data.
> 'dec' has to
> ++  // be reset until there is more data.
> ++  // !br->eos_ && src < src_last: this cannot happen as either the
> buffer is
> ++  // fully read, either enough has been read to reach 'src_last'.
> ++  // src >= src_last: 'src_last' is reached, all is fine. 'src' can
> actually go
> ++  // beyond 'src_last' in case the image is cropped and an LZ77
> goes further.
> ++  // The buffer might have been enough or there is some left. 'br-
> >eos_' does
> ++  // not matter.
> ++  assert(!dec->incremental_ || (br->eos_ && src < src_last) || src
> >= src_last);
> ++  if (dec->incremental_ && br->eos_ && src < src_last) {
> +     RestoreState(dec);
> +-  } else if (!br->eos_) {
> ++  } else if ((dec->incremental_ && src >= src_last) || !br->eos_) {
> +     // Process the remaining rows corresponding to last row-block.
> +     if (process_func != NULL) {
> +       process_func(dec, row > last_row ? last_row : row);
> +--
> +2.40.0
> diff --git a/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
> b/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
> index 4defdd5e42..0728ca60f5 100644
> --- a/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
> +++ b/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
> @@ -16,6 +16,7 @@ LIC_FILES_CHKSUM =
> "file://COPYING;md5=6e8dee932c26f2dab503abf70c96d8bb \
>  SRC_URI =
> "http://downloads.webmproject.org/releases/webp/${BP}.tar.gz \
>             file://CVE-2023-1999.patch \
>             file://CVE-2023-5129.patch \
> +           file://CVE-2023-4863.patch \
>             "
>  SRC_URI[sha256sum] =
> "7bf5a8a28cc69bcfa8cb214f2c3095703c6b73ac5fba4d5480c205331d9494df"
>  
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#189826):
> https://lists.openembedded.org/g/openembedded-core/message/189826
> Mute This Topic: https://lists.openembedded.org/mt/102291764/3616702
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> anuj.mittal@intel.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Sambu, Soumya Oct. 31, 2023, 8:16 a.m. UTC | #2
Yes Anuj, I will correct it and will send v2.

Regards,
Soumya
diff mbox series

Patch

diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch
new file mode 100644
index 0000000000..4c60cbc9a1
--- /dev/null
+++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch
@@ -0,0 +1,109 @@ 
+From 95ea5226c870449522240ccff26f0b006037c520 Mon Sep 17 00:00:00 2001
+From: Vincent Rabaud <vrabaud@google.com>
+Date: Mon, 11 Sep 2023 16:06:08 +0200
+Subject: [PATCH] Fix invalid incremental decoding check.
+
+The first condition is only necessary if we have not read enough
+(enough being defined by src_last, not src_end which is the end
+of the image).
+The second condition now fits the comment below: "if not
+incremental, and we are past the end of buffer".
+
+BUG=oss-fuzz:62136
+
+Change-Id: I0700f67c62db8e1c02c2e429a069a71e606a5e4f
+
+CVE: CVE-2023-4863
+
+Upstream-Status: Backport [https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520]
+
+Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
+---
+ ...x-invalid-incremental-decoding-check.patch | 48 +++++++++++++++++++
+ src/dec/vp8l_dec.c                            | 15 +++++-
+ 2 files changed, 61 insertions(+), 2 deletions(-)
+ create mode 100644 0001-Fix-invalid-incremental-decoding-check.patch
+
+diff --git a/0001-Fix-invalid-incremental-decoding-check.patch b/0001-Fix-invalid-incremental-decoding-check.patch
+new file mode 100644
+index 0000000..21f67f4
+--- /dev/null
++++ b/0001-Fix-invalid-incremental-decoding-check.patch
+@@ -0,0 +1,48 @@
++From 95ea5226c870449522240ccff26f0b006037c520 Mon Sep 17 00:00:00 2001
++From: Vincent Rabaud <vrabaud@google.com>
++Date: Mon, 11 Sep 2023 16:06:08 +0200
++Subject: [PATCH] Fix invalid incremental decoding check.
++
++The first condition is only necessary if we have not read enough
++(enough being defined by src_last, not src_end which is the end
++of the image).
++The second condition now fits the comment below: "if not
++incremental, and we are past the end of buffer".
++
++BUG=oss-fuzz:62136
++
++Change-Id: I0700f67c62db8e1c02c2e429a069a71e606a5e4f
++---
++ src/dec/vp8l_dec.c | 15 +++++++++++++--
++ 1 file changed, 13 insertions(+), 2 deletions(-)
++
++diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
++index 5ab34f56..809b1aa9 100644
++--- a/src/dec/vp8l_dec.c
+++++ b/src/dec/vp8l_dec.c
++@@ -1233,9 +1233,20 @@ static int DecodeImageData(VP8LDecoder* const dec, uint32_t* const data,
++   }
++
++   br->eos_ = VP8LIsEndOfStream(br);
++-  if (dec->incremental_ && br->eos_ && src < src_end) {
+++  // In incremental decoding:
+++  // br->eos_ && src < src_last: if 'br' reached the end of the buffer and
+++  // 'src_last' has not been reached yet, there is not enough data. 'dec' has to
+++  // be reset until there is more data.
+++  // !br->eos_ && src < src_last: this cannot happen as either the buffer is
+++  // fully read, either enough has been read to reach 'src_last'.
+++  // src >= src_last: 'src_last' is reached, all is fine. 'src' can actually go
+++  // beyond 'src_last' in case the image is cropped and an LZ77 goes further.
+++  // The buffer might have been enough or there is some left. 'br->eos_' does
+++  // not matter.
+++  assert(!dec->incremental_ || (br->eos_ && src < src_last) || src >= src_last);
+++  if (dec->incremental_ && br->eos_ && src < src_last) {
++     RestoreState(dec);
++-  } else if (!br->eos_) {
+++  } else if ((dec->incremental_ && src >= src_last) || !br->eos_) {
++     // Process the remaining rows corresponding to last row-block.
++     if (process_func != NULL) {
++       process_func(dec, row > last_row ? last_row : row);
++--
++2.40.0
++
+diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
+index 186b0b2..59a9e64 100644
+--- a/src/dec/vp8l_dec.c
++++ b/src/dec/vp8l_dec.c
+@@ -1241,9 +1241,20 @@ static int DecodeImageData(VP8LDecoder* const dec, uint32_t* const data,
+   }
+
+   br->eos_ = VP8LIsEndOfStream(br);
+-  if (dec->incremental_ && br->eos_ && src < src_end) {
++  // In incremental decoding:
++  // br->eos_ && src < src_last: if 'br' reached the end of the buffer and
++  // 'src_last' has not been reached yet, there is not enough data. 'dec' has to
++  // be reset until there is more data.
++  // !br->eos_ && src < src_last: this cannot happen as either the buffer is
++  // fully read, either enough has been read to reach 'src_last'.
++  // src >= src_last: 'src_last' is reached, all is fine. 'src' can actually go
++  // beyond 'src_last' in case the image is cropped and an LZ77 goes further.
++  // The buffer might have been enough or there is some left. 'br->eos_' does
++  // not matter.
++  assert(!dec->incremental_ || (br->eos_ && src < src_last) || src >= src_last);
++  if (dec->incremental_ && br->eos_ && src < src_last) {
+     RestoreState(dec);
+-  } else if (!br->eos_) {
++  } else if ((dec->incremental_ && src >= src_last) || !br->eos_) {
+     // Process the remaining rows corresponding to last row-block.
+     if (process_func != NULL) {
+       process_func(dec, row > last_row ? last_row : row);
+--
+2.40.0
diff --git a/meta/recipes-multimedia/webp/libwebp_1.2.4.bb b/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
index 4defdd5e42..0728ca60f5 100644
--- a/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
+++ b/meta/recipes-multimedia/webp/libwebp_1.2.4.bb
@@ -16,6 +16,7 @@  LIC_FILES_CHKSUM = "file://COPYING;md5=6e8dee932c26f2dab503abf70c96d8bb \
 SRC_URI = "http://downloads.webmproject.org/releases/webp/${BP}.tar.gz \
            file://CVE-2023-1999.patch \
            file://CVE-2023-5129.patch \
+           file://CVE-2023-4863.patch \
            "
 SRC_URI[sha256sum] = "7bf5a8a28cc69bcfa8cb214f2c3095703c6b73ac5fba4d5480c205331d9494df"