<?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-release@openeuler.org</ContactDetails>
		<IssuingAuthority>openEuler release SIG</IssuingAuthority>
	</DocumentPublisher>
	<DocumentTracking>
		<Identification>
			<ID>openEuler-HotPatchSA-2024-1036</ID>
		</Identification>
		<Status>Final</Status>
		<Version>1.0</Version>
		<RevisionHistory>
			<Revision>
				<Number>1.0</Number>
				<Date>2024-10-21</Date>
				<Description>Initial</Description>
			</Revision>
		</RevisionHistory>
		<InitialReleaseDate>2024-10-21</InitialReleaseDate>
		<CurrentReleaseDate>2024-10-21</CurrentReleaseDate>
		<Generator>
			<Engine>openEuler HotPatchSA Tool V1.0</Engine>
			<Date>2024-10-21</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:

tracing/timerlat: Only clear timer if a kthread exists

The timerlat tracer can use user space threads to check for osnoise and
timer latency. If the program using this is killed via a SIGTERM, the
threads are shutdown one at a time and another tracing instance can start
up resetting the threads before they are fully closed. That causes the
hrtimer assigned to the kthread to be shutdown and freed twice when the
dying thread finally closes the file descriptors, causing a use-after-free
bug.

Only cancel the hrtimer if the associated thread is still around. Also add
the interface_lock around the resetting of the tlat_var-&gt;kthread.

Note, this is just a quick fix that can be backported to stable. A real
fix is to have a better synchronization between the shutdown of old
threads and the starting of new ones.(CVE-2024-46845)</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 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-1036</URL>
		</Reference>
		<Reference Type="openEuler CVE">
			<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-46845</URL>
		</Reference>
		<Reference Type="Other">
			<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-46845</URL>
		</Reference>
	</DocumentReferences>
	<HotPatchTree 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="src">
			<FullProductName ProductID="kernel-6.6.0-28.0.0.34.oe2403-ACC-1-1" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-28.0.0.34.oe2403-ACC-1-1.src.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="x86_64">
			<FullProductName ProductID="patch-kernel-6.6.0-28.0.0.34.oe2403-ACC-1-1" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">patch-kernel-6.6.0-28.0.0.34.oe2403-ACC-1-1.x86_64.rpm</FullProductName>
		</Branch>
		<Branch Type="Package Arch" Name="aarch64">
			<FullProductName ProductID="patch-kernel-6.6.0-28.0.0.34.oe2403-ACC-1-1" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">patch-kernel-6.6.0-28.0.0.34.oe2403-ACC-1-1.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:tracing/timerlat: Only clear timer if a kthread existsThe timerlat tracer can use user space threads to check for osnoise andtimer latency. If the program using this is killed via a SIGTERM, thethreads are shutdown one at a time and another tracing instance can startup resetting the threads before they are fully closed. That causes thehrtimer assigned to the kthread to be shutdown and freed twice when thedying thread finally closes the file descriptors, causing a use-after-freebug.Only cancel the hrtimer if the associated thread is still around. Also addthe interface_lock around the resetting of the tlat_var-&gt;kthread.Note, this is just a quick fix that can be backported to stable. A realfix is to have a better synchronization between the shutdown of oldthreads and the starting of new ones.</Note>
		</Notes>
		<ReleaseDate>2024-10-21</ReleaseDate>
		<CVE>CVE-2024-46845</CVE>
		<ProductStatuses>
			<Status Type="Fixed">
				<ProductID>openEuler-24.03-LTS</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-10-21</DATE>
				<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-HotPatchSA-2024-1036</URL>
			</Remediation>
		</Remediations>
	</Vulnerability>
</cvrfdoc>