| Message ID | 4dcd5e0a0bb43c23850e3a711fc7e2230575d245.1698789786.git.steve@sakoman.com |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [kirkstone,1/3] libxml2: Patch CVE-2023-45322 | expand |
I'm surprised this one does apply in kirkstone as there is this security issue already fixed as 2023-5129 (see dunfell commit https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7dce529515baa843ba3e5c89b2ad605b9845c59b and a bit more details in https://lists.openembedded.org/g/openembedded-core/message/189262 ) Is https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 really related to CVE-2023-4863 ? On Tue, Oct 31, 2023 at 11:05 PM Steve Sakoman <steve@sakoman.com> 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> > Signed-off-by: Steve Sakoman <steve@sakoman.com> > --- > .../webp/files/CVE-2023-4863.patch | 53 +++++++++++++++++++ > meta/recipes-multimedia/webp/libwebp_1.2.4.bb | 1 + > 2 files changed, 54 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..2b1817822c > --- /dev/null > +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch > @@ -0,0 +1,53 @@ > +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> > +--- > + 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 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" > > -- > 2.34.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#189873): > https://lists.openembedded.org/g/openembedded-core/message/189873 > Mute This Topic: https://lists.openembedded.org/mt/102307907/3617156 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > martin.jansa@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Thanks for reviewing Martin! I'll drop this patch until there is further clarification on the need for it. Steve On Tue, Oct 31, 2023 at 1:39 PM Martin Jansa <martin.jansa@gmail.com> wrote: > > I'm surprised this one does apply in kirkstone as there is this security issue already fixed as 2023-5129 (see dunfell commit https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7dce529515baa843ba3e5c89b2ad605b9845c59b and a bit more details in https://lists.openembedded.org/g/openembedded-core/message/189262 ) > > Is https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 really related to CVE-2023-4863 ? > > On Tue, Oct 31, 2023 at 11:05 PM Steve Sakoman <steve@sakoman.com> 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> >> Signed-off-by: Steve Sakoman <steve@sakoman.com> >> --- >> .../webp/files/CVE-2023-4863.patch | 53 +++++++++++++++++++ >> meta/recipes-multimedia/webp/libwebp_1.2.4.bb | 1 + >> 2 files changed, 54 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..2b1817822c >> --- /dev/null >> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch >> @@ -0,0 +1,53 @@ >> +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> >> +--- >> + 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 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" >> >> -- >> 2.34.1 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#189873): https://lists.openembedded.org/g/openembedded-core/message/189873 >> Mute This Topic: https://lists.openembedded.org/mt/102307907/3617156 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [martin.jansa@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
Hi Martin, Steve, Debian has mentioned https://chromium.googlesource.com/webm/libwebp.git/+/95ea5226c870449522240ccff26f0b006037c520%5E%21/#F0 as followup commit for CVE-2023-4863 [Reference: https://security-tracker.debian.org/tracker/CVE-2023-4863]. This commit was suggested in Bugzilla SUSE as well - https://bugzilla.suse.com/show_bug.cgi?id=1215231#c13 Regards, Soumya ________________________________ From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> on behalf of Steve Sakoman via lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> Sent: Wednesday, November 1, 2023 7:21 PM To: Martin Jansa <martin.jansa@gmail.com> Cc: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core][kirkstone 3/3] libwebp: Fix CVE-2023-4863 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. Thanks for reviewing Martin! I'll drop this patch until there is further clarification on the need for it. Steve On Tue, Oct 31, 2023 at 1:39 PM Martin Jansa <martin.jansa@gmail.com> wrote: > > I'm surprised this one does apply in kirkstone as there is this security issue already fixed as 2023-5129 (see dunfell commit https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7dce529515baa843ba3e5c89b2ad605b9845c59b and a bit more details in https://lists.openembedded.org/g/openembedded-core/message/189262 ) > > Is https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 really related to CVE-2023-4863 ? > > On Tue, Oct 31, 2023 at 11:05 PM Steve Sakoman <steve@sakoman.com> 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> >> Signed-off-by: Steve Sakoman <steve@sakoman.com> >> --- >> .../webp/files/CVE-2023-4863.patch | 53 +++++++++++++++++++ >> meta/recipes-multimedia/webp/libwebp_1.2.4.bb | 1 + >> 2 files changed, 54 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..2b1817822c >> --- /dev/null >> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch >> @@ -0,0 +1,53 @@ >> +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> >> +--- >> + 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 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" >> >> -- >> 2.34.1 >> >> >> >>
On Thu, Nov 2, 2023 at 7:57 AM Sambu, Soumya <Soumya.Sambu@windriver.com> wrote: > Hi Martin, Steve, > > Debian has mentioned > https://chromium.googlesource.com/webm/libwebp.git/+/95ea5226c870449522240ccff26f0b006037c520%5E%21/#F0 as > followup commit for CVE-2023-4863 [Reference: > https://security-tracker.debian.org/tracker/CVE-2023-4863]. > > This commit was suggested in Bugzilla SUSE as well - > https://bugzilla.suse.com/show_bug.cgi?id=1215231#c13 > Aha, thanks for this information, can you please make sure that all supported branches receive this additional commit (preferably in less confusing set of .patch files, e.g. apply both from CVE-2023-4863.patch and remove CVE-2023-5129.patch)? > > Regards, > Soumya > ------------------------------ > *From:* openembedded-core@lists.openembedded.org < > openembedded-core@lists.openembedded.org> on behalf of Steve Sakoman via > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > *Sent:* Wednesday, November 1, 2023 7:21 PM > *To:* Martin Jansa <martin.jansa@gmail.com> > *Cc:* openembedded-core@lists.openembedded.org < > openembedded-core@lists.openembedded.org> > *Subject:* Re: [OE-core][kirkstone 3/3] libwebp: Fix CVE-2023-4863 > > 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. > > Thanks for reviewing Martin! > > I'll drop this patch until there is further clarification on the need for > it. > > Steve > > On Tue, Oct 31, 2023 at 1:39 PM Martin Jansa <martin.jansa@gmail.com> > wrote: > > > > I'm surprised this one does apply in kirkstone as there is this security > issue already fixed as 2023-5129 (see dunfell commit > https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7dce529515baa843ba3e5c89b2ad605b9845c59b > and a bit more details in > https://lists.openembedded.org/g/openembedded-core/message/189262 ) > > > > Is > https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520 > really related to CVE-2023-4863 ? > > > > On Tue, Oct 31, 2023 at 11:05 PM Steve Sakoman <steve@sakoman.com> > 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> > >> Signed-off-by: Steve Sakoman <steve@sakoman.com> > >> --- > >> .../webp/files/CVE-2023-4863.patch | 53 +++++++++++++++++++ > >> meta/recipes-multimedia/webp/libwebp_1.2.4.bb | 1 + > >> 2 files changed, 54 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..2b1817822c > >> --- /dev/null > >> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch > >> @@ -0,0 +1,53 @@ > >> +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> > >> +--- > >> + 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 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" > >> > >> -- > >> 2.34.1 > >> > >> > >> > >> >
Sure Martin. Regards, Soumya ________________________________ From: Martin Jansa <martin.jansa@gmail.com> Sent: Thursday, November 2, 2023 12:35 PM To: Sambu, Soumya <Soumya.Sambu@windriver.com> Cc: steve@sakoman.com <steve@sakoman.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> Subject: Re: [OE-core][kirkstone 3/3] libwebp: Fix CVE-2023-4863 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. On Thu, Nov 2, 2023 at 7:57 AM Sambu, Soumya <Soumya.Sambu@windriver.com<mailto:Soumya.Sambu@windriver.com>> wrote: Hi Martin, Steve, Debian has mentioned https://chromium.googlesource.com/webm/libwebp.git/+/95ea5226c870449522240ccff26f0b006037c520%5E%21/#F0<https://urldefense.com/v3/__https://chromium.googlesource.com/webm/libwebp.git/*/95ea5226c870449522240ccff26f0b006037c520*5E*21/*F0__;KyUlIw!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZES2_uY8Fc$> as followup commit for CVE-2023-4863 [Reference: https://security-tracker.debian.org/tracker/CVE-2023-4863<https://urldefense.com/v3/__https://security-tracker.debian.org/tracker/CVE-2023-4863__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESjF4z9k0$>]. This commit was suggested in Bugzilla SUSE as well - https://bugzilla.suse.com/show_bug.cgi?id=1215231#c13<https://urldefense.com/v3/__https://bugzilla.suse.com/show_bug.cgi?id=1215231*c13__;Iw!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESlK1lfDg$> Aha, thanks for this information, can you please make sure that all supported branches receive this additional commit (preferably in less confusing set of .patch files, e.g. apply both from CVE-2023-4863.patch and remove CVE-2023-5129.patch)? Regards, Soumya ________________________________ From: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>> on behalf of Steve Sakoman via lists.openembedded.org<https://urldefense.com/v3/__http://lists.openembedded.org__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESh49m9Ao$> <steve=sakoman.com@lists.openembedded.org<mailto:sakoman.com@lists.openembedded.org>> Sent: Wednesday, November 1, 2023 7:21 PM To: Martin Jansa <martin.jansa@gmail.com<mailto:martin.jansa@gmail.com>> Cc: openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org> <openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>> Subject: Re: [OE-core][kirkstone 3/3] libwebp: Fix CVE-2023-4863 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. Thanks for reviewing Martin! I'll drop this patch until there is further clarification on the need for it. Steve On Tue, Oct 31, 2023 at 1:39 PM Martin Jansa <martin.jansa@gmail.com<mailto:martin.jansa@gmail.com>> wrote: > > I'm surprised this one does apply in kirkstone as there is this security issue already fixed as 2023-5129 (see dunfell commit https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7dce529515baa843ba3e5c89b2ad605b9845c59b<https://urldefense.com/v3/__https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=7dce529515baa843ba3e5c89b2ad605b9845c59b__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZEScr20Fek$> and a bit more details in https://lists.openembedded.org/g/openembedded-core/message/189262<https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/message/189262__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESjPybAj8$> ) > > Is https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520<https://urldefense.com/v3/__https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESSSDnB1o$> really related to CVE-2023-4863 ? > > On Tue, Oct 31, 2023 at 11:05 PM Steve Sakoman <steve@sakoman.com<mailto:steve@sakoman.com>> wrote: >> >> From: Soumya Sambu <soumya.sambu@windriver.com<mailto: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://urldefense.com/v3/__https://nvd.nist.gov/vuln/detail/CVE-2023-4863__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESN3Jhg9I$> >> https://security-tracker.debian.org/tracker/CVE-2023-4863<https://urldefense.com/v3/__https://security-tracker.debian.org/tracker/CVE-2023-4863__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESjF4z9k0$> >> https://bugzilla.redhat.com/show_bug.cgi?id=2238431#c12<https://urldefense.com/v3/__https://bugzilla.redhat.com/show_bug.cgi?id=2238431*c12__;Iw!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZES05Tfi6Y$> >> >> Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com<mailto:soumya.sambu@windriver.com>> >> Signed-off-by: Steve Sakoman <steve@sakoman.com<mailto:steve@sakoman.com>> >> --- >> .../webp/files/CVE-2023-4863.patch | 53 +++++++++++++++++++ >> meta/recipes-multimedia/webp/libwebp_1.2.4.bb<https://urldefense.com/v3/__http://libwebp_1.2.4.bb__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESIBRfcng$> | 1 + >> 2 files changed, 54 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..2b1817822c >> --- /dev/null >> +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch >> @@ -0,0 +1,53 @@ >> +From 95ea5226c870449522240ccff26f0b006037c520 Mon Sep 17 00:00:00 2001 >> +From: Vincent Rabaud <vrabaud@google.com<mailto: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<https://urldefense.com/v3/__https://github.com/webmproject/libwebp/commit/95ea5226c870449522240ccff26f0b006037c520__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESSSDnB1o$>] >> + >> +Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com<mailto:soumya.sambu@windriver.com>> >> +--- >> + 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 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<https://urldefense.com/v3/__http://libwebp_1.2.4.bb__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESIBRfcng$> b/meta/recipes-multimedia/webp/libwebp_1.2.4.bb<https://urldefense.com/v3/__http://libwebp_1.2.4.bb__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESIBRfcng$> >> index 4defdd5e42..0728ca60f5 100644 >> --- a/meta/recipes-multimedia/webp/libwebp_1.2.4.bb<https://urldefense.com/v3/__http://libwebp_1.2.4.bb__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESIBRfcng$> >> +++ b/meta/recipes-multimedia/webp/libwebp_1.2.4.bb<https://urldefense.com/v3/__http://libwebp_1.2.4.bb__;!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESIBRfcng$> >> @@ -16,6 +16,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=6e8dee932c26f2dab503abf70c96d8bb \ >> SRC_URI = "http://downloads.webmproject.org/releases/webp/${BP}.tar.gz<https://urldefense.com/v3/__http://downloads.webmproject.org/releases/webp/$*7BBP*7D.tar.gz__;JSU!!AjveYdw8EvQ!dCWYSGOx1CaWD6bo_z2fXrO_SLJmHSwBqYAiEz6BStoDU8EgzhbTekVavdCW9BQFzdU-qaYmWwDozSkBKZESU0waYcM$> \ >> file://CVE-2023-1999.patch \ >> file://CVE-2023-5129.patch \ >> + file://CVE-2023-4863.patch \ >> " >> SRC_URI[sha256sum] = "7bf5a8a28cc69bcfa8cb214f2c3095703c6b73ac5fba4d5480c205331d9494df" >> >> -- >> 2.34.1 >> >> >> >>
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..2b1817822c --- /dev/null +++ b/meta/recipes-multimedia/webp/files/CVE-2023-4863.patch @@ -0,0 +1,53 @@ +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> +--- + 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 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"