<?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-24.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-1794</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2024-07-05</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2024-07-05</InitialReleaseDate>
		<CurrentReleaseDate>2024-07-05</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler SA Tool V1.0</Engine>
			<Date>2024-07-05</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-24.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:

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in
vast majority of cases, now and then it causes instability. This leads
to system crashes and other undefined behaviour. After a lot of testing
(30+ hours) while also doing a lot of frequency switches, we can&apos;t
observe any instability issues anymore when doing reparenting to stable
clock like 24 MHz oscillator.(CVE-2023-52882)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: uvc: use correct buffer size when parsing configfs lists

This commit fixes uvc gadget support on 32-bit platforms.

Commit 0df28607c5cb (&quot;usb: gadget: uvc: Generalise helper functions for
reuse&quot;) introduced a helper function __uvcg_iter_item_entries() to aid
with parsing lists of items on configfs attributes stores. This function
is a generalization of another very similar function, which used a
stack-allocated temporary buffer of fixed size for each item in the list
and used the sizeof() operator to check for potential buffer overruns.
The new function was changed to allocate the now variably sized temp
buffer on heap, but wasn&apos;t properly updated to also check for max buffer
size using the computed size instead of sizeof() operator.

As a result, the maximum item size was 7 (plus null terminator) on
64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just
barely enough, 3 is definitely too small for some of UVC configfs
attributes. For example, dwFrameInteval, specified in 100ns units,
usually has 6-digit item values, e.g. 166666 for 60fps.(CVE-2024-36895)

In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can&apos;t clear the bus
reset event flag in irq_handler, because we won&apos;t service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with &quot;modprobe firewire_ohci debug=-1&quot; (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won&apos;t be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.(CVE-2024-36950)</Note>
		<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.

openEuler Security has rated this update as having a security impact of medium. 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">Medium</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-SA-2024-1794</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52882</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36895</URL>
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36950</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52882</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36895</URL>
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36950</URL>
		</Reference>
	</DocumentReferences>
	<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
		<Branch Type="Product Name" Name="openEuler">
			<FullProductName ProductID="openEuler-24.03-LTS" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">openEuler-24.03-LTS</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="bpftool-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="bpftool-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="bpftool-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-debugsource-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-headers-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-source-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="kernel-tools-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
			<FullProductName ProductID="python3-perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="src">
			<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.src.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:

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in
vast majority of cases, now and then it causes instability. This leads
to system crashes and other undefined behaviour. After a lot of testing
(30+ hours) while also doing a lot of frequency switches, we can&apos;t
observe any instability issues anymore when doing reparenting to stable
clock like 24 MHz oscillator.</Note>
		</Notes>
		<ReleaseDate>2024-07-05</ReleaseDate>
		<CVE>CVE-2023-52882</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.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-07-05</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: uvc: use correct buffer size when parsing configfs lists

This commit fixes uvc gadget support on 32-bit platforms.

Commit 0df28607c5cb (&quot;usb: gadget: uvc: Generalise helper functions for
reuse&quot;) introduced a helper function __uvcg_iter_item_entries() to aid
with parsing lists of items on configfs attributes stores. This function
is a generalization of another very similar function, which used a
stack-allocated temporary buffer of fixed size for each item in the list
and used the sizeof() operator to check for potential buffer overruns.
The new function was changed to allocate the now variably sized temp
buffer on heap, but wasn&apos;t properly updated to also check for max buffer
size using the computed size instead of sizeof() operator.

As a result, the maximum item size was 7 (plus null terminator) on
64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just
barely enough, 3 is definitely too small for some of UVC configfs
attributes. For example, dwFrameInteval, specified in 100ns units,
usually has 6-digit item values, e.g. 166666 for 60fps.</Note>
		</Notes>
		<ReleaseDate>2024-07-05</ReleaseDate>
		<CVE>CVE-2024-36895</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>None</Description>
			</Threat>
		</Threats>
		<CVSSScoreSets>
			<ScoreSet>
				<BaseScore>3.9</BaseScore>
				<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
			</ScoreSet>
		</CVSSScoreSets>
		<Remediations>
			<Remediation Type="Vendor Fix">
				<Description>kernel security update</Description>
				<DATE>2024-07-05</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</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="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can&apos;t clear the bus
reset event flag in irq_handler, because we won&apos;t service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with &quot;modprobe firewire_ohci debug=-1&quot; (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won&apos;t be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.</Note>
		</Notes>
		<ReleaseDate>2024-07-05</ReleaseDate>
		<CVE>CVE-2024-36950</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS</ProductID>
			</Status>
		</ProductStatuses>
		<Threats>
			<Threat Type="Impact">
				<Description>None</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-07-05</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>