<?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-SP3</DocumentTitle>
	<DocumentType>Security Advisory</DocumentType>
	<DocumentPublisher Type="Vendor">
		<ContactDetails>openeuler-release@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler release SIG</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-HotPatchSA-2024-1027</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2024-08-16</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2024-08-16</InitialReleaseDate>
		<CurrentReleaseDate>2024-08-16</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler HotPatchSA Tool V1.0</Engine>
			<Date>2024-08-16</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-SP3</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:

bpf: Fix stackmap overflow check on 32-bit arches

The stackmap code relies on roundup_pow_of_two() to compute the number
of hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code.

The commit in the fixes tag actually attempted to fix this, but the fix
did not account for the UB, so the fix only works on CPUs where an
overflow does result in a neat truncation to zero, which is not
guaranteed. Checking the value before rounding does not have this
problem.(CVE-2024-26883)

In the Linux kernel, the following vulnerability has been resolved:

USB: core: Fix deadlock in usb_deauthorize_interface()

Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface&apos;s parent
USB device.

The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected.  As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete.  But usb_deauthorize_interface() can&apos;t complete
until the device lock has been released, and the lock won&apos;t be
released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.

Reported-and-tested by: Yue Sun &lt;samsun1006219@gmail.com&gt;
Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;(CVE-2024-26934)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.

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/zh/security/security-bulletins/detail/?id=openEuler-HotPatchSA-2024-1027</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-26883</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-26934</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26883</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26934</URL>
		</Reference>
	</DocumentReferences>
	<HotPatchTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-5.10.0-182.0.0.95.oe2203sp3-ACC-1-3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-182.0.0.95.oe2203sp3-ACC-1-3.src.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="patch-kernel-5.10.0-182.0.0.95.oe2203sp3-ACC-1-3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">patch-kernel-5.10.0-182.0.0.95.oe2203sp3-ACC-1-3.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="patch-kernel-5.10.0-182.0.0.95.oe2203sp3-ACC-1-3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">patch-kernel-5.10.0-182.0.0.95.oe2203sp3-ACC-1-3.aarch64.rpm</FullProductName>
		</Branch>
	</HotPatchTree>
	<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-26883</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.8</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-HotPatchSA-2024-1027</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
	<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1">
		<Notes>
			<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface s parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected.  As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete.  But usb_deauthorize_interface() can t completeuntil the device lock has been released, and the lock won t bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun &lt;samsun1006219@gmail.com&gt;Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;</Note>
		</Notes>
		<ReleaseDate>2024-08-16</ReleaseDate>
		<CVE>CVE-2024-26934</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-22.03-LTS-SP3</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>High</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>7.8</BaseScore>
				<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-08-16</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-HotPatchSA-2024-1027</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>