cvrf2cusa/cvrf/2021/cvrf-openEuler-SA-2021-1423.xml
Jia Chao 0b34274085 git mv
Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-07-25 09:57:37 +08:00

142 lines
8.1 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
<DocumentTitle xml:lang="en">An update for netty is now available for openEuler-20.03-LTS-SP1 and openEuler-20.03-LTS-SP2</DocumentTitle>
<DocumentType>Security Advisory</DocumentType>
<DocumentPublisher Type="Vendor">
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
<IssuingAuthority>openEuler security committee</IssuingAuthority>
</DocumentPublisher>
<DocumentTracking>
<Identification>
<ID>openEuler-SA-2021-1423</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2021-11-05</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2021-11-05</InitialReleaseDate>
<CurrentReleaseDate>2021-11-05</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2021-11-05</Date>
</Generator>
</DocumentTracking>
<DocumentNotes>
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">netty security update</Note>
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for netty is now available for openEuler-20.03-LTS-SP1 and openEuler-20.03-LTS-SP2.</Note>
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. %package help Summary: Documents for Buildarch: noarch Requires: man info Provides: -javadoc = - Obsoletes: -javadoc &lt; - %description help Man pages and other related documents for .
Security Fix(es):
The Snappy frame decoder function doesn&apos;t restrict the chunk length which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well. This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk.(CVE-2021-37137)
The Bzip2 decompression decoder function doesn&apos;t allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack(CVE-2021-37136)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for netty is now available for openEuler-20.03-LTS-SP1 and openEuler-20.03-LTS-SP2.
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">netty</Note>
</DocumentNotes>
<DocumentReferences>
<Reference Type="Self">
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2021-1423</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-37137</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-37136</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-37137</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-37136</URL>
</Reference>
</DocumentReferences>
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
<Branch Type="Product Name" Name="openEuler">
<FullProductName ProductID="openEuler-20.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">openEuler-20.03-LTS-SP1</FullProductName>
<FullProductName ProductID="openEuler-20.03-LTS-SP2" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP2">openEuler-20.03-LTS-SP2</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="netty-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">netty-4.1.13-12.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="netty-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP2">netty-4.1.13-12.oe1.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="noarch">
<FullProductName ProductID="netty-help-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">netty-help-4.1.13-12.oe1.noarch.rpm</FullProductName>
<FullProductName ProductID="netty-help-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP2">netty-help-4.1.13-12.oe1.noarch.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="netty-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">netty-4.1.13-12.oe1.src.rpm</FullProductName>
<FullProductName ProductID="netty-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP2">netty-4.1.13-12.oe1.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="netty-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">netty-4.1.13-12.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="netty-4.1.13-12" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP2">netty-4.1.13-12.oe1.x86_64.rpm</FullProductName>
</Branch>
</ProductTree>
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The Snappy frame decoder function doesn&apos;t restrict the chunk length which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well. This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk.</Note>
</Notes>
<ReleaseDate>2021-11-05</ReleaseDate>
<CVE>CVE-2021-37137</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
<ProductID>openEuler-20.03-LTS-SP2</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.5</BaseScore>
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>netty security update</Description>
<DATE>2021-11-05</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2021-1423</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="2" xml:lang="en">The Bzip2 decompression decoder function doesn&apos;t allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack</Note>
</Notes>
<ReleaseDate>2021-11-05</ReleaseDate>
<CVE>CVE-2021-37136</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
<ProductID>openEuler-20.03-LTS-SP2</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.5</BaseScore>
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>netty security update</Description>
<DATE>2021-11-05</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2021-1423</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>