<?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</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-1569</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.</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:

tun: avoid double free in tun_free_netdev

Avoid double free in tun_free_netdev() by moving the
dev-&gt;tstats and tun-&gt;security allocs to a new ndo_init routine
(tun_net_init()) that will be called by register_netdevice().
ndo_init is paired with the desctructor (tun_free_netdev()),
so if there&apos;s an error in register_netdevice() the destructor
will handle the frees.

BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605

CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
Hardware name: Red Hat KVM, BIOS
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
____kasan_slab_free mm/kasan/common.c:346 [inline]
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:1723 [inline]
slab_free_freelist_hook mm/slub.c:1749 [inline]
slab_free mm/slub.c:3513 [inline]
kfree+0xac/0x2d0 mm/slub.c:4561
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae(CVE-2021-47082)

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:

usb: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev-&gt;bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev-&gt;bos will be NULL and those accesses will result in a
crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 &lt;48&gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn&apos;t accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)

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.

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-1569</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47082</URL>
			<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-2023-52477</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-47082</URL>
			<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-2023-52477</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" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">openEuler-22.03-LTS</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="kernel-tools-devel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.136.0.163.oe2203.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.136.0.163.oe2203.src.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="kernel-headers-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-headers-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-devel-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-tools-devel-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debugsource-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-source-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-debuginfo-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">python3-perf-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">kernel-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">bpftool-5.10.0-60.136.0.163.oe2203.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-5.10.0-60.136.0.163" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">perf-5.10.0-60.136.0.163.oe2203.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:

tun: avoid double free in tun_free_netdev

Avoid double free in tun_free_netdev() by moving the
dev-&gt;tstats and tun-&gt;security allocs to a new ndo_init routine
(tun_net_init()) that will be called by register_netdevice().
ndo_init is paired with the desctructor (tun_free_netdev()),
so if there&apos;s an error in register_netdevice() the destructor
will handle the frees.

BUG: KASAN: double-free or invalid-free in selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605

CPU: 0 PID: 25750 Comm: syz-executor416 Not tainted 5.16.0-rc2-syzk #1
Hardware name: Red Hat KVM, BIOS
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:247
kasan_report_invalid_free+0x55/0x80 mm/kasan/report.c:372
____kasan_slab_free mm/kasan/common.c:346 [inline]
__kasan_slab_free+0x107/0x120 mm/kasan/common.c:374
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:1723 [inline]
slab_free_freelist_hook mm/slub.c:1749 [inline]
slab_free mm/slub.c:3513 [inline]
kfree+0xac/0x2d0 mm/slub.c:4561
selinux_tun_dev_free_security+0x1a/0x20 security/selinux/hooks.c:5605
security_tun_dev_free_security+0x4f/0x90 security/security.c:2342
tun_free_netdev+0xe6/0x150 drivers/net/tun.c:2215
netdev_run_todo+0x4df/0x840 net/core/dev.c:10627
rtnl_unlock+0x13/0x20 net/core/rtnetlink.c:112
__tun_chr_ioctl+0x80c/0x2870 drivers/net/tun.c:3302
tun_chr_ioctl+0x2f/0x40 drivers/net/tun.c:3311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
		</Notes>
		<ReleaseDate>2024-05-11</ReleaseDate>
		<CVE>CVE-2021-47082</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>4.4</BaseScore>
				<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</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-1569</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:

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</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-1569</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:

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</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-1569</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="4" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev-&gt;bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev-&gt;bos will be NULL and those accesses will result in a
crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 &lt;48&gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn&apos;t accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.</Note>
		</Notes>
		<ReleaseDate>2024-05-11</ReleaseDate>
		<CVE>CVE-2023-52477</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>Medium</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>5.5</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</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-1569</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="5" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="5" 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</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-1569</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>