On Tue, 2023-10-31 at 04:37 +0000, Soumya via lists.openembedded.org wrote: > From: Soumya Sambu <[email protected]> > > 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 <[email protected]> > --- > .../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 <[email protected]> > +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 <[email protected]> > +--- > + ...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 <[email protected]> > ++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 (#189828): https://lists.openembedded.org/g/openembedded-core/message/189828 Mute This Topic: https://lists.openembedded.org/mt/102291764/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
