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

316 lines
16 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 kernel is now available for openEuler-22.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-2024-1571</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-05-11</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-05-11</InitialReleaseDate>
<CurrentReleaseDate>2024-05-11</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-05-11</Date>
</Generator>
</DocumentTracking>
<DocumentNotes>
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP2.</Note>
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was.(CVE-2021-47182)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.(CVE-2021-47211)
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using
skb_queue_empty when deciding how much data to append using
ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to
transhdrlen for messages with a non-zero length, which results in
corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original
intent.(CVE-2024-26752)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.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">kernel</Note>
</DocumentNotes>
<DocumentReferences>
<Reference Type="Self">
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47182</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47211</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26752</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47182</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47211</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26752</URL>
</Reference>
</DocumentReferences>
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
<Branch Type="Product Name" Name="openEuler">
<FullProductName ProductID="openEuler-22.03-LTS-SP2" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">openEuler-22.03-LTS-SP2</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="perf-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-devel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-devel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debugsource-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-headers-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-source-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-5.10.0-153.53.0.131.oe2203sp2.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="kernel-headers-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-headers-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-source-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">python3-perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-tools-devel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-debugsource-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-5.10.0-153.53.0.131" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP2">kernel-devel-5.10.0-153.53.0.131.oe2203sp2.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">In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was.</Note>
</Notes>
<ReleaseDate>2024-05-11</ReleaseDate>
<CVE>CVE-2021-47182</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP2</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>0.0</BaseScore>
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-05-11</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571</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">In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
</Notes>
<ReleaseDate>2024-05-11</ReleaseDate>
<CVE>CVE-2021-47211</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.03-LTS-SP2</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>0.0</BaseScore>
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-05-11</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6_append_data
l2tp_ip6_sendmsg needs to avoid accounting for the transport header
twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using
skb_queue_empty when deciding how much data to append using
ip6_append_data.
However, the code which performed the calculation was incorrect:
ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to
transhdrlen for messages with a non-zero length, which results in
corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original
intent.</Note>
</Notes>
<ReleaseDate>2024-05-11</ReleaseDate>
<CVE>CVE-2024-26752</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-22.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:H/A:N</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-05-11</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>