An update for kernel is now available for openEuler-22.03-LTS-SP2 Security Advisory openeuler-security@openeuler.org openEuler security committee openEuler-SA-2024-1571 Final 1.0 1.0 2024-05-11 Initial 2024-05-11 2024-05-11 openEuler SA Tool V1.0 2024-05-11 kernel security update An update for kernel is now available for openEuler-22.03-LTS-SP2. 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->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->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(&sk->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) 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. High kernel https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571 https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47182 https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47211 https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26752 https://nvd.nist.gov/vuln/detail/CVE-2021-47182 https://nvd.nist.gov/vuln/detail/CVE-2021-47211 https://nvd.nist.gov/vuln/detail/CVE-2024-26752 openEuler-22.03-LTS-SP2 perf-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-devel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-tools-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-tools-devel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-debugsource-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm python3-perf-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-headers-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-source-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-tools-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm python3-perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.aarch64.rpm kernel-5.10.0-153.53.0.131.oe2203sp2.src.rpm kernel-headers-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-tools-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-tools-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-source-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm python3-perf-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm python3-perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm perf-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm perf-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-tools-devel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-debuginfo-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-debugsource-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm kernel-devel-5.10.0-153.53.0.131.oe2203sp2.x86_64.rpm 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->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->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. 2024-05-11 CVE-2021-47182 openEuler-22.03-LTS-SP2 Low 0.0 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N kernel security update 2024-05-11 https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571 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. 2024-05-11 CVE-2021-47211 openEuler-22.03-LTS-SP2 Low 0.0 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N kernel security update 2024-05-11 https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571 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(&sk->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. 2024-05-11 CVE-2024-26752 openEuler-22.03-LTS-SP2 High 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N kernel security update 2024-05-11 https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1571